>
> Look at t/subclass.t in the DBI distribution.
>
> But is subclassing the DBI actually the best way to implement this?
>
> At first sight I'd think it would be better to teach DBD::Chart about
> how to talk to other drivers. Perhaps something like
>
> $dbh_chart = DBI->connect("dbi:Chart:...", ...);
> $dbh_ora = DBI->connect("dbi:Oracle:SALES", ...);
> $dbh_mysql = DBI->connect("dbi:mysql:LOG", ...);
>
> Teach DBD::Chart about names for database handles:
>
> $chart_dbh->{chart_dbh_names}->{Sales} = $dbh_ora;
> $chart_dbh->{chart_dbh_names}->{Log} = $dbh_mysql;
>
> Than add some way to indicate which named database handle to use
> for the statement. For example:
>
> $chart_sth = $chart_dbh->prepare(qq{
> SELECT LINEGRAPH FROM
> (SELECT * FROM Sales.someTable WHERE this=that...)
> WHERE WIDTH=400 AND HEIGHT=....
> });
>
> But other ways (that are simpler to parse) may be better.
>
> Tim.
Thanks for the info/insights.
Your approach might be an easier first step, but it raises a bit of a
question wrt how
a connection gets "named"...At the DBI level, its simply the DSN text (sans
'dbi:Drivername:'), right ?
So apps have to code that extra bit of stuff (tiny tho it may be), rather
than
coding for DBI as is (except for using the 'DBIx::Chart' in place of 'DBI').
By subclassing DBI, the app sees a dbh that looks the same (or nearly the
same)
as a current DBI dbh, and the SQL syntax doesn't require 3(or 4) part
naming.
And so it looks to the app like all those DBMS's out there just suddenly
acquired the ability to natively render charts. (assuming there
aren't any naming collisions between DBD::Chart's keywords, and
the data-source)
However, I was considering an explicit connection naming syntax for
DBIx::Chart, eg,
DBIx::Chart->connect('dbi:MySQL:some.host.name', $user, $passwd, {
Identity => 'conn1', ...});
which might also make any future attempts at distributed SQL a bit easier,
eg,
SELECT ora.*,syb.* FROM myoraconn.ora
JOIN mysybconn.syb
ON ora.col1 = syb.col1;
(Perhaps DBIx::Mariposa ?)
(Unless you can be coaxed into believing such an addition to DBI itself
might be worthwhile ? Then DBD::Chart could use some magic to get the names
of
all open connections from DBI ? !^)
I've rambled enough; either approach means I've got some serious parsing to
do...
Dean Arnold
