In particular, the DBI must not mandate impossible levels of support from
the drivers. It will benefit you nothing if the DBI is immaculate and
wonderful and incredibly all-singing and all-dancing, but no-one can write a
driver for it because the requirements cannot be met by the actual DBMS that
Perl + DBI needs to work with.
I concur. Like CPAN as a whole, DBI's strength is in it's complete and
near universal coverage of all databases, and insanely great (and
occasisionally greatly insane) drivers that do strange and wonderful things.
If we start sacrificing drivers by raising the bar too high, DBI as a
whole suffers. Anyone proposing new features for DBI needs to be
extremely careful of CYJ syndrome.
Can't You Just (or sometimes Could You Just) syndrome is described here.
http://c2.com/cgi/wiki?CouldYouJust
http://www.oreillynet.com/pub/wlg/3593
http://c2.com/cgi/wiki?JustIsaDangerousWord
Go read them now. I'll wait...
This sort of behaviour can play a big part in ending up with second
system problems.
I have an increasing suspicion that having open design processes like
the Tim's call for comments plays a big part in it as well.
People are free to comment on things that 1) They won't have to
implement themselves and (in some cases, but not you Duncan) 2) They
think they know what they are talking about, but really have no idea
what it means underneath the surface.
In any case, I still propose that DBI2 split the driver interface into
Roles. The main "DBI2::Role::Transport" role does ONLY what DBI does
best now. That is, connecting to the database, preparing and sending
queries, and fetching the results.
Forget the current ->tables interface. Drivers can OPTIONALLY implement
the DBI2::Role::Schema interface to handle interrogation of the database
schema. The current way we handle it is really messy by my standards,
and could use a dedicated interface.
As you invent major new features for DBI2, implement them roles.
DBI2::Role::Transational, DBI2::Role::RFC90210 (the super flashy Beverly
Hills feature), etc etc.
Exactly what these roles should be I don't want to state with any
certainty. That's the sort of thing that Tim, with his complete
understanding of the issues, should be doing on his own.
But I _would_ certainly like to see schema/table stuff separated from
the base connection/query functionality.
While I'm on the topic of DBI, one other feature I'd like to see would
be something like better support for large objects or various types.
In my personal DBI wrapper I've been using plain SCALAR refs as
parameters to signify a BLOB, so I can pass by reference without a copy
of a potentially large memory chunk, and then having to do
driver-specific translation to bind variables (Oracle) or what have you.
Some base way of default method defining a BLOB object (whether provided
in memory, or pointing at a file handle to pull the data from at commit
time) in would be really nice. Even if the way I have to pass the blobs
to each driver differs, I'd like to be at least be able to say,
This is a DBI2::Data::BLOB object (or something functionally equivalent).
Adam K
