[Dbix-class] RFC: Load from SQL

[Brandon Black]

On 7/10/07, Jeff Zucker <jeff at vpservices.com> wrote:
> Hi all (and especially Brandon Black),
>

Hi :)

> Jeff Zucker (jZed), here (author/maintainer of DBD::CSV, DBD::AnyData,
> SQL::Statement and various other DBI related modules).  I wanted a DBIC
> loader that would work with the DBDs that do not store metadata (other
> than column names) so I wrote a little wrapper around SQL::Translator
> and DBIx::Class::File that will parse DDL on the fly, create DBIC schema
> classes in memory (and optionally to file).
>
> In addition to serving as a loader for DBD::CSV etc. this wrapper
> supports file-less prototyping of schemas for any DBD.  You can just
> feed it SQL statements (DDL and optionally also DML) to create and
> populate a test schema and begin using DBIx::Class on it directly
> without creating any module files (and if you use temp tables, without
> any db footprint either).
>
> The module and a working sample script can be found at
>
>     http://www.perlmonks.org/?node_id=623778
>
> Castaway tells me that Matt suggested this should be named something
> like DBIx::Class::Schema::Loader::SQL.  Should I release this as a
> separate module or (as I'd prefer) just submit it as a patch to
> DBIx::Class::Schema::Loader?  If the latter, what version should I patch
> against?
>

Looks like some fun hacking :)

Patching against Schema::Loader would be great.  If you want to get up
and running quickly, patching locally against 0.04001 would work ok.
Alternatively, you could do an svn checkout of the repo
(http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class-Schema-Loader).
 Or jump on irc.perl.org #dbix-class for realtime discussion (and then
maybe we can get you commit rights to make a new branch, etc).

In theory DBIx::Class::Schema::Loader::Base is agnostic to DBI-isms,
whereas DBIx::Class::Schema::Loader::DBI is DBI-specific, with
DBD-specific subclasses.  If you want to treat those oddball DBD's as
if they were not DBI-like, you could make a new
DBIx::Class::Schema::Loader::Foo.   However, if your backends are in
fact DBD's, one way to support them would be to bring them up to speed
with regard to the optional DBI metadata methods [1].

DBI's metadata methods actually provide all of the information needed
for Loader to operate without special DBD-specific Loader code, but
virtually none of the DBD's implement every single metadata method (or
at least, not consistently).  DBD::Pg is getting really close, if they
would finally release a new version of their trunk that I patched up
several months ago to fill in the final gap.

Just a thought, as opposed to putting more custom code in
DBIx::Class::Schema::Loader.

-- Brandon

[1] When I say "DBI metadata methods", I mean $dbh->tables(),
$dbh->primary_key(), $dbh->column_info(), $dbh->type_info(),
$dbh->foreign_key_info(), and $dbh->statistics_info() (I added that
one, since it was the last piece of data we needed that didn't
technically have a DBI interface).