On Thu, Dec 27, 2001 at 11:58:25AM +0000, Matt Sergeant wrote:
> 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.
Or maybe this would work:
$dbh = DBI->connect("dbi:Oracle:...", "","", { RootClassThingy => "MySubclass"
});
Giving a class hierarchy like:
DBI::db
`-- MySubclass::db
`-- MySubclass::Oracle::db
Effectively MySubclass::db would replace the current "...::Default" in AnyDBD
(and this new RootClassThingy mechanism would probably replace the current
way subclassing the DBI is handled).
[And, in case your wondering, "RootClassThingy" would have a more sensible name :-]
Does all that seem workable?
This reminds me... I was wondering if they'd be any value in having
the same kind of per-database class hierarchy for statement handles.
I can't see much need off-hand but you never know... we should at
least not preculde it.
Tim.
