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.

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

Reply via email to