At 10:25 PM +1000 7/9/05, Adam Kennedy wrote:
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.
That sounds like a great idea and a good starting place on which to
build certain design issues.
In fact, I have already been implementing something similar to that
in my 'Rosetta' database access library for over a year now. It has
a concept of "feature support lists" where each Rosetta Engine/driver
must take a standard fine-ish-grained checklist and programmatically
declare which list items it officially supports.
An application can see what an Engine/driver claims to support before
trying to use it, and will know whether or not the Engine/driver
can meet its needs or not. An Engine's/driver's declaration can be
read by invoking the features() method of some Rosetta Interface
objects.
An additional use for this feature is that a comprehensive common
test suite for all Engines/drivers can consult features() prior to
running its tests so that it can "skip" any tests that an
Engine/driver doesn't claim to support; it will only invoke and
pass/fail features that the Engine/driver claims to support.
See the Rosetta::Details documentation section 'FEATURE SUPPORT
VALIDATION' for the main summary of "feature support lists".
But I _would_ certainly like to see schema/table stuff separated
from the base connection/query functionality.
I agree. When you get down to it, schema/table/etc reverse
engineering is a very complicated and involved process. Fetching
lists of tables or columns etc should no more be built in than SQL
parsing or generating. In short, anything that can normally be
fetched or changed using ordinary SQL statements should be left out
of the DBI core; let wrappers do that stuff through the SQL pipe that
DBI provides. This said, it is still very useful for DBI to provide
a function for fetching a list of auto-detectable data sources, so
that should stay.
On a similar note, utility functions like quote() should be left out
of the DBI core, and left to either a separate module or someone's
wrapper, since it's firmly related to SQL generation. If people want
DBI itself to handle stuff like that for them, they should use host
parameters for the literals in question.
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.
I second that. Have API methods for fetching or storing by-the-chunk
pieces of LOBs that one could not do with a traditional bind_param()
etc since the whole thing won't fit in RAM at once.
-- Darren Duncan
