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.
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.
----- 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.
>
>
