I have an additional reply to the following ...

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.

One of the reasons I like this idea is that it lets DBI define multiple Roles that may be mutually exclusive and accomplish the same task in different ways.

For example, the idea of whether the interface will accept SQL AST objects in addition to or instead of SQL strings. The standard DBI2::Role::Transport will take SQL strings and only SQL strings, as the current DBI does. There can be an additional Role for each AST.

In that situation, there are several case scenarios depending on the type of database being used and what the driver maker is willing to support.

1. The first case is the common database server that always takes its input as string SQL. In this case, the standard string-taking Role will be the most native fit for it, and any AST-supporting Roles would have to be, in some fashion, implemented as wrappers on top of this, converting their contents to string SQL for the database.

It is assumed that the AST in question would come with its own set of SQL generators, either in the same distribution or a separate distribution that is an extension to it. If the DBI driver writer chooses to implement the relevant AST-taking Role, it would presumably use the AST's own SQL generator to implement that support, so the driver writer hardly has any work to do of their own. Or, if the DBI driver writer does not choose to implement the Role, then users of said AST would use it as or with a DBI wrapper that invokes the SQL generating functionality itself and passes the result to DBI2::Role::Transport.

2. The second case is a usually-embedded database server or library that does not take string SQL as its native input. In this case, some sort of AST-supporting Role would be the most native fit for it, since it is probably easier for that DBI driver to extract the information it needs from the AST than to parse string SQL; the DBI2::Role::Transport Role would have to be, in some fashion, implemented as a wrapper on top of this, which parses string SQL into an AST. Most likely, an externally destributed SQL parser would be the best choice, so it can be improved independently of the driver, as with any SQL generators. (SQL::Statement is an example of this already being done.)

Now, if support for a string-SQL interface is mandatory for all DBI drivers, then it is possible that all AST-taking Roles can be implemented on top of the string-taking Role. As is the case with DBI v1. But, for the sake of those drivers that want ASTs internally, having a way for them to get that input natively, through officially sanctioned appropriate Roles, that lets those drivers save themselves a lot of work and the system is potentially much faster and easier to improve, without sacrificing compatability.

A separate advantage of this Roles thing is backwards compatability due to a multi-versioned API. If we wish to implement a significant API or implementation change in DBI after DBI 2 is launched, we can be free to do so without breaking older programs because they will by definition be writing against a specific API version. We just have to maintain a Role for each distinct version that maps what the application expects to how things work in the background.

I liken this to a new feature in Mac OS X starting with 10.4 Tiger; versioned KPIs (kernal programming interfaces); from now on, it is a lot easier for Apple to release significantly changed kernals in newer Mac OS X versions without breaking any applications or drivers, because those specify a versioned API which continues to exist as a wrapper. See http://arstechnica.com/reviews/os/macosx-10.4.ars/4 for what I'm talking about.

However it's done, I'm thinking something akin to that would be good for DBI.

-- Darren Duncan

Reply via email to