On Fri, Feb 01, 2002 at 10:46:12AM -0800, Jeff Zucker wrote:
> Tim Bunce wrote:
> >
> > Umm, carrying on from there... move %get_info_constants into DBD::Oracle::GetInfo
> > and make get_info do:
>
> So is this the way to do get_info() for DBD::CSV and DBD::AnyData?
Well it's certainly one way.
> The
> situation for those is a bit more complex since the return values depend
> not only on the driver version in use, but also on the SQL::Statement
> version in use.
>
> sub get_info {
> my($dbh, $info_type) = @_;
> my $v;
> if ($SQL::Statement::VERSION > 1) {
> require DBD::SQL_Statement::GetInfo;
> $v = $DBD::SQL_Statement::GetInfo::info{int($info_type)};
> }
> else {
> require DBD::SQL_Statement_XS::GetInfo;
> $v = $DBD::SQL_Statement_XS::GetInfo::info{int($info_type)};
> }
> $v = &$v($dbh, $info_type) if ref $v eq 'CODE';
> return $v;
> }
There's probably cleaner ways of doing it.
The drivers could certainly try looking up $info_type in whichever
SQL::Statement they're using (giving it 'first refusal' to answer
any requests). SQL::Statement would only define values that are
appropriate to it.
If the lookup in SQL::Statement doesn't return a defined value the
lookup the $info_type in the drivers own hash.
> The situation for DBD::Excel will be even more complex since it will
> depend on the DBD in use, the SQL::Statement in use,
Those are catered for but what I described above.
> and on the version of Excel in use.
Well that's why you've got the $dbh passed to you :)
Fetch and cache the version and use code refs to do-the-right-thing.
> If one wanted to get even more complex, one would need
> to determine the versions of sub-modules also (e.g.
> Spreadsheet::ParseExcel in the Excel case or XML::Twig/XML::Parser when
> AnyData is handling XML). To know how detailed to get, we'd have to
> know the kinds of things get_info() will ultimately be used for. In
> other words, what constants will be required by DBI and how will they be
> used?
I do plan to define a minimum set of values that drivers will be
expected to support.
> I know that I will be using the ones related to SQL syntax for my
> own purposes in SQL::Statement, but which of the others will actually be
> used by DBI to change DBI behaviour?
>
> Also: shouldn't we be wrapping the requires in evals?
Yes, and the execution of code refs. Then something like:
return $dbh->set_err(1,$@) if $@;
Tim.
