Replying to myself, ...
I believe that this fundamental design change can be accomplished with almost
full or entirely backwards-compatibility to existing DBI-using codebases.
This partly by a "DBI" package still being available which essentially provides
shims for people saying "DBI->connect(...)" that wrap say "DBD::Pg->new(...)"
for legacy code, while newer code would write the latter directly instead and
cut out the shim.
Either way, the result of invoking the above would be an object providing the
API that a $dbh currently has, though its package name may be different.
While it should carry a full major-version update because it isn't guaranteed
compatible, I see that it could be made backwards-compatible much to the extent
that Perl 5.14 will run code written for Perl 5.8 or 5.6 or such.
I believe that the very first version with this fundamental change should keep
all other kinds of changes to a minimum, to aid transition, and then other API
changes can happen later, with new API versions.
-- Darren Duncan
Darren Duncan wrote:
To be brief, ...
I don't know if this has come up in past discussions about the next
major DBI version, but I'll say it now, since its also what I'm doing
with my own DBI-alike ecosystem to be.
I believe that DBI should go away as an actual piece of code and instead
be replaced by an API specification document, taking PSGI as inspiration.
A DBD would be re-defined as a module that implements said documented
API specification, and that's it.
The DBDs would be mutually severed from there being a mandatory shared
DBI codebase which can aid in their maturity and optimizability.
The existing DBI code can be refactored into reusable utility modules or
roles that a DBD can *optionally* depend on in its implementation. This
also means, for example, that said DBI roles could more freely be Moose
roles, while DBDs that don't want that overhead aren't required to use
it. Or the shared parts could be identical to the current DBI, more or
less, same dependencies. Or the choice between XS vs pure Perl is more
clean, and is a quality of just each individual DBD.
The concept of gophering in DBI would change into a "middleware" concept.
The concept of driver-specific methods, like pg_*, just become ordinary
DBD methods that are beyond what is defined by the DBI spec.
So the new DBD is anything that quacks like a DBI, as defined by
documentation.
And of course, the DBI document would be versioned, and part of the API
it defines is that one can programmatically query what version(s) of the
DBI spec the DBD provides.
So what say you?
-- Darren Duncan
