Therefore, I've decided to consider a more general solution and see what other Module Authors would think about a DBIx::Schema tool.
As I see it there are two aspects to this idea: SQL generation and DBI calls. Both have been handled to various extents by several other tools on CPAN. For just SQL generation, the SQL Fairy project (SQL::Translator) comes to mind. The most complete solution for this, that I know of, is Dave Rolsky's Alzabo. Alzabo is not well-suited, however, for my problem, which only requires a simple solution to create a table if it doesn't yet exist or drop a table if it does exist. Alzabo is overkill and simply adds a huge number of dependencies I can't afford to fill.
My Class::DBI::DDL solution is close to what I'd like, but with a few changes I could remove it's dependency on Class::DBI and make it more generally applicable. It requires nothing but a database handle and a schema specification for a table. It will generate the "CREATE TABLE" or "DROP TABLE" commands when needed and requested. Adding support for another database may require nothing as it has a general solution that should work for most situations, but a small module can be added to make it's support superior.
My questions to the module authors are: Has this been done before and I missed the simple solution to this problem? Otherwise, is this idea a good one? If you've taken a look at Class::DBI::DDL (http://search.cpan.org/~hanenkamp/Class-DBI-DDL-1.01/lib/Class/DBI/DDL.pm), besides removing the Class::DBI dependencies, is there anything you think should be changed about the interface? Any other comments?
Thanks! Sterling
-- <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> Andrew Sterling Hanenkamp http://Andrew.Sterling.Hanenkamp.com/ [EMAIL PROTECTED] / [EMAIL PROTECTED]
I've taken the trash out innumerable times,
I've taken the trash out in inclement climes,
I've taken the trash out 'cuz that's what I do,
But I *won't* take the trash out when you tell me to.
-- Larry Wall
