Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jk2addict (4946)

jk2addict
  (email not shown publicly)
http://today.icantfocus.com/blog/
AOL IM: chrislaco (Add Buddy, Send Message)
Yahoo! ID: chrislaco@sbcglobal.net (Add User, Send Message)
Jabber: laco@scribblewerks.com

Journal of jk2addict (4946)

Monday August 08, 2005
12:32 PM

SQL::Translator::RecursiveSchema

[ #26184 ]

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
$schema->tables('NewTable')->fields('id')->type('varchar')->size(36)->nul lable(0);

#alter the existing table
$schema->tables('NewTable')->fields('id')->type('varchar')->size(25)->nul lable(1);

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Or more to the point, I like this:

    $schema->tables('NewTable')->fields('id')->type('varchar')->size(36)->nullable(0 );

    Better than this:

        my $field = $schema->get_table('NewTable')->get_field('id');
        $field->size(36);
        $field->type('varchar');
        $field->nullable(0);