Re: DBI drivers by duck-typing

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
>