On Fri, Jul 30, 2004 at 05:14:27PM -0700, Masahji Stewart wrote:
> Hey Tim,
>
> I had a question about a module that I was designing to do SQL
> translation between databases. I was going to implement it as a
> database driver (DBD::Translate). Here's how it would be used:
The core translation code ought to live outside the DBI in an SQL::*
module so it's reusable in other contexts.
That module could then be used either by a DBI subclass, or by a
"layered driver" such as the DBD::Translate you're proposing.
The new version of DBD::Multiplex that'll be included in DBI v2 will
have hooks for callbacks that can be used for SQL translation.
Your SQL::* translation module could be easily plugged in that way.
Tim.
> <code>
> use DBI;
>
> my $real_handle = DBI->connect('dbi:mysql:localhost', 'username',
> 'password');
>
> # this means the underlying DBD::Translate module will parse oracle
> queries
> # and convert them to whatever database that the $real_handle is
> configured
> to use (mysql).
> my $translate_handle = DBI->connect('dbi:translate:oracle',
> $real_handle);
>
> # obviously an Oracle query which will now be executing on the mysql
> database from the handle above.
> my $sth = $translate_handle->prepare('SELECT DECODE(user_id, NULL, '0',
> user_id) FROM users');
> $sth->execute();
>
> while( my $row = $sth->fetchrow_hashref ) {
> # ...
> }
> </code>
>
> After looking around at your DBI TODO list, I noticed that the
> $dbh->preparse method seems like this. I think. What exactly does the
> preparse method do? is it anything like this?
> If so, will you require the driver implementers to handle the parsing
> of their own language?
>
> Please let me know and thanks in advance,
>
>
> -masahji
>
