On Wed, 26 Dec 2001, Tim Bunce wrote: > On Mon, Dec 10, 2001 at 09:22:16PM -0000, Matt Sergeant wrote: > > What I can see doing here is returning a subclass of DBI using similar rules > > to what's in AnyDBD... However, one thing AnyDBD does, which makes it > > useful, is it does its magic through both ODBC and ADO drivers. This might > > not be necessary since ODBC/ADO already do some automatic query fixup. > > However maybe you'd wish to do more than query fixup - like transaction > > abstraction. > > > > I think it should be embedded direct into the DBI->connect sub, rather than > > a separate module. > > That implies that the AnyDBD mechanism no longer uses a wrapper > around the $dbh but returns and uses the raw $dbh itself. That's > fine as I was thinking along those lines anyway. > > To maintain method namespace separation we can mandate that application > methods must start with a capital letter and be mixed case (whereas > DBI methods are all lowercase or all uppercase). > > The "magic" that AnyDBD does for ODBC and ADO drivers to work out > what's "behind" the driver will almost certainly be neatly abstracted > by the new get_info() method. > > So my preference is currently for adding an attribute to DBI->connect > that triggers the AnyDBD mechanism and then the return $dbh will be > blessed into a new subclass instead of "DBI::db".
One thing I was thinking about for this is it might ruin people's day who have overridden DBI::db. To make it work, we could move DBI::db methods into DBI::db::base, and make DBI::db a subclass of that, possibly with some AnyDBD generated classes in between. -- <!-- Matt --> <:->Get a smart net</:->
