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 >