This post by malte sparked a flame of curiousity for me, Handel, and SQL::Translator::Schema. One of the things I wanted to do was abstract the schema into a perl file that populates a SQL::Translator::Schema object. From there I would generate SQL scripts for the various target databases. I decided that I'd rather create the base schema using the objects rather in YAML or something else. I consider the objects the first class citizens, and creating the base schema in one of the parsers is like translating a copy of a copy instead of the original. But I digress..
My gripe is that in order to do multiple things to a table or field object, one must make/hold a reference to the original and make multiple calls. This is ok if the schema is small, but for a large schema, the extra code get's to be a pain in the butt. I want something smaller; something of a chained nature.
Enter my thoughts for SQL::Translatore::RecursiveSchema. The name is only for the sake of this argument. It probably isn't the best. For that matter, if a proof of concept works fine, the code should really be worked into the stock SQL::T::Schema me thinks.
my $schema = SQL::Translator::RecursiveSchema->new(name => 'MySchema');
#create a new table
#alter the existing table
Sure, the stock add_table() returns a table object, and add_field() returns a field object, but size() returns the size; whereas in this form, it returns the same field object. Same goes for all of the field properties, and table properties. There is of course, the question of how to actually just display the field->size value. Maybe some stringify magick can deal with that. Most of this magic could be done by subclassing the existing Schema::* modules.
Best case, it becomes useful. Worst case, it's a fun experiment.