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
