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".
> And beyond that, we should think what fixups we should be doing... I'm sure
> we want the ODBC date stuff (that's {d <date>}, {t <time>} and {ts
> <datetime>}), but what else? Maybe outer join abstraction? Something to
> think about.
All of that is planned to be covered by the new SQL rewriting mechanism
that's being added to the DBI. ODBC escape sequences will trigger method
calls that will return the replacement text.
Tim.
> ----- Original Message -----
> From: "Tim Bunce" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, December 10, 2001 4:48 PM
> Subject: DBIx::AnyDBD
>
>
> > I'm thinking strongly of merging DBIx::AnyDBD into the DBI.
> >
> > DBIx::AnyDBD is orthogonal and complementary to the planned
> > support for parsing and rewriting ODBC SQL escape sequences.
> > Both are key parts of the DBI growing to address portability
> > among SQL dialects.
> >
> > I like the principle behind the module and Matt Sergeant, the author,
> > has joined dbi-dev for this discussion.
> >
> > The merging might range from a simple bundling all the way to a rewrite.
> > But will probably fall between those two extremes.
> >
> > At this point I'd just like to solicit some feedback from anyone
> > who's used DBIx::AnyDBD and got any ideas or comments etc about it
> > and how it could be improved.
> >
> > Tim.
> >
> > p.s. This isn't a high priority as I'll probably be exploring the issues
> > during a MySQL to Oracle migration I'll be working on in the coming
> months.
> >
> >
>
