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

Reply via email to