[DBIx-Class-Devel] DBIx::Introspector

fREW Schmidt frioux at gmail.com
Sat Jun 1 00:22:22 GMT 2013


I started on DBIx::Introspector today, because I was writing a blog
post and got carried away.  Also mezcal.

Anyway, I'll show some of you what's up at YAPC surely, but I want
to at least get everyone's gears turning.  Here goes.

I am factoring DBIx::Introspector out of DBIx::Class::Storage.  As per
ribasushi's recommendation I'll be doing at least two passes on the
code.

I hope to model those who went before me and make the simplest thing
possible (ie NOT dbic) w/o sacrificing anything.  The problem, as
always, is that databases are complicated.

DBIx::Introspector should introspect database handles. (IE: what is
the driver?  what is the rdbms?  what version is the rdbms?  do they
have $x plugin installed?  what odbc_driver are we using?)

The API for DBIx::Introspector will probably look something like this:

  my $i = DBIx::Introspector->new($dbh);
  warn $i->get('db_name');
  warn $i->get('db_version');

If you are doing something weird and need to jump start it, you should
be able to do this:

  my $i = DBIx::Introspector->new($dbh, { db_name => 'MSSQL' });
  warn $i->get('db_version');

(eg when someone connects to SQL Server over Gopher.  Yes people
really do that.)

DBIx::Connector2 (pick some other name, I can't think of one now) will
handle various inputs and give you a $dbh.  The idea is that right now
::Storage can do things like, set certain attributes at connect time.
Is it possible to have ::Introspector and ::Connector2 separate tools?
Probably, but only with very careful factoring.

At some point we need to decide on a canonical set of database names.
Same goes for parameters.  Generally in the past we follow SQLT,
presumably because it came first.

Lastly, hopes and dreams time, what if after this is all stable and
working, we made a DBIx::Introspector::Probe that would discover DB
capabilities in a jquery manner?  IE right now we *generally* key on
the database version, and every now and then we'll actually try
something and if it dies assume that we can't do that.  What if we did
the latter as a matter of course, at the very least for standards
things?  MSSQL, for exmaple, supports the standard quotes and has for
a LONG time, yet we still use [] because why should we bother to check
versions when [] will always work?  Just a thought.

See you guys in a couple days!
--
fREW Schmidt
http://blog.afoolishmanifesto.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.scsys.co.uk/pipermail/dbix-class-devel/attachments/20130531/f7159cb7/attachment.pgp


More information about the DBIx-Class-Devel mailing list