Re: DBI drivers by duck-typing

Greg Sabino Mullane wrote:
>> 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.
> 
> I'm having a hard time envisioning how this would work in practice. What I 
> see is lots of duplicated code across the DBDs. So a "DBI bug" would be 
> handled by updating the API, bumping the version, and waiting for individual 
> DBDs to implement it? A recipe for a large collection of supported API versions 
> out in the wild, I would imagine.

I envision that DBDs will tend to still have a shared dependency with each other 
as they do now, and that shared code essentially being what DBI is now.  So when 
the API is updated to handle this "DBI bug", then generally only the shared 
dependency would need to be updated, same as now.

The main difference in my proposal is that this code sharing is no longer 
*mandatory* to use the API.

>> The concept of driver-specific methods, like pg_*, just become ordinary DBD 
>> methods that are beyond what is defined by the DBI spec.
> 
> Seems a sure recipe for namespace collisions. Also makes it much harder to 
> spot any DBMS-specific hacks in your Perl code.

You can still use namespaces under my proposal.  The difference is that it is no 
longer mandatory for the shared code to be updated for a new DBMS to be supported.

As for DBMS-specific hacks, those still abound today, because every DBMS has 
unique SQL syntax and unique behaviors for some of the same syntax; DBI has 
never abstracted these away; it just prevents the need for some other kinds of 
DBMS-specific hacks.

-- Darren Duncan