On Mon, Dec 15, 2003 at 04:10:12PM -0600, Andrew Sterling Hanenkamp wrote: > I was toying with the idea of a schema manager to use in conjunction > with Class::DBI that would be relatively driver independent. As such, I > wrote a small module named Class::DBI::DDL and presented to the > cdbi-talk list for discussion. The response appears to be: what's this > got to do with Class::DBI? > > 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
Sterling, As one of the authors of SQL::Translator, I can comment a bit on your project ideas. First off, this has sorta has been done numerous times. Just search for "schema" on search.cpan.org and browse the results. Some of the others who've tried building object models for relational databases include SQL::Schema and DBIx::SystemCatalog (DBIx-Renderer, to an extent, and many others to be sure). By the 0.02 release of SQL::Translator, I found myself badly in need of this kind of layer, too, but, not liking what I saw, I decided to reinvent my own wheel, so S::T has one, too (SQL::Translator::Schema). It's quite difficult to come up with a single object model that encompasses the abilities and options of every RDBMS. Some have procedures and views and foreign keys and such, some don't. Each has different extensions to SQL and myriad options for tables and indices and such. You're more than welcome to try to come up with something definitive and/or exhaustive, but it will probably be exhausting to you! Cf. these other modules to see if you'd rather contribute to those projects first. If you like the SQLFairy Schema objects (though some on the team even don't like what I wrote!), then you could rip those out to start with. HTH, ky
pgp00000.pgp
Description: PGP signature
