On Thu, Dec 27, 2001 at 05:18:50PM +0000, Matt Sergeant wrote:
> On Thu, 27 Dec 2001, Tim Bunce wrote:
>
> > On Thu, Dec 27, 2001 at 04:04:55PM +0000, Matt Sergeant wrote:
> > > On Thu, 27 Dec 2001, Tim Bunce wrote:
> > >
> > > > Or maybe this would work:
> > > >
> > > > $dbh = DBI->connect("dbi:Oracle:...", "","", { RootClassThingy =>
>"MySubclass" });
> > > >
> > > > Giving a class hierarchy like:
> > > >
> > > > DBI::db
> > > > `-- MySubclass::db
> > > > `-- MySubclass::Oracle::db
> > >
> > > But to what purpose? If we fixed AnyDBD so that it could accept a $dbh,
> > > then built-in DBI magic wouldn't be needed. However I thought the aim was
> > > not to ship/include AnyDBD, but to use it's detection routines so SQL
> > > rewriting worked?
> >
> > No. SQL (ODBC escape sequence) rewriting will be handled by the drivers.
> > DBD::ODBC can just leave them alone. I'm not certain about DBD::ADO but a
> > quick web search seems to suggest that SQLOLEDB also supports them.
> >
>(http://msdn.microsoft.com/library/en-us/ado270/htm/mdrefsqlprovspec.asp?frame=true)
> >
> > The aim of _this_ discussion is to explore adding AnyDBD functionailty
> > to the DBI. That's unrelated to SQL rewriting (other than complementing
> > it as a way to increase application portability). See my original
> > message "DBIx::AnyDBD is orthogonal and complementary to the planned
> > support for parsing and rewriting ODBC SQL escape sequences."
>
> In that case, your design looks perfect :-)
:-)
It does mean we've lost simple compatibility with DBIx::AnyDBD, but
manual conversion shouldn't be a big effort.
> We just need to come up with a good name for the option.
Or perhaps a good name for the concept from which we can derive a
good name for the option.
Suggestions anyone?
Tim.
> (Of course I'd still like to provide a version
> of AnyDBD that allowed you to pass it a $dbh, rather than it creating one
> for you, but that's an aside here).
>
> --
> <!-- Matt -->
> <:->Get a smart net</:->
>
