On Mon, Nov 26, 2001 at 04:25:16PM +0100, Steffen Goeldner wrote:
> >
> > As internal implementation, fine. As user interface, probably not.
> > I think I'd rather stick with the "use DBI qw(...)", but allow
> > things like "use DBI qw(:get_info_subsetfoo)". Few applications
> > will use more than a handful of distinct GetInfo calls anyway.
> >
> > Another issue here is the difference between
> >
> > $h->{SQL_FOO}
>
> AFAIK, there are few options: $h->{SQL_FOO} triggers a FETCH and
> FETCH calls dbih_get_attr_k, right?
After passing through the driver, which may choose to handle it itself.
> dbih_get_attr_k(h, keysv, dbikey)
> SV *h;
> SV *keysv;
> int dbikey;
> {
> ...
> else if (htype==DBIt_DB && strnEQ(key, "SQL_", 4)) {
> /* XXX DBIt_ST ? */
> valuesv = dbih_get_info(h, key, keylen);
That presumes that _all_ attributes begining with SQL_ are
'get_info' attributes. That may not be the case. I'd suggest
else if (htype==DBIt_DB && strnEQ(key, "SQL_", 4) && gi_code =
get_info_name2code(key)) {
..
> Of course, dbih_get_info needs to be written. I think, it should
>
> 1) map the symbolic name to the numeric code
> (via %DBI::Const::GetInfo?)
> 2) call $dbh->get_info($code)
There's also the question of whether each particular item of 'info'
can be cached for the handle it's being called on (see cacheit in
dbih_get_attr_k).
> And, of course, I need a remedy for my XS-phobia ;-)
:)
> > and $h->{SQL_FOO()} (or $h->{+SQL_FOO} etc)
>
> Personally, I would not import these symbols (I like namespaces).
> I know, other people like that ...
On reflection I agree that DBI attributes should be consistently
fetched by name, not a numeric value.
The $h->get_info method is still open to question. Since we have
to provide a name to number mapping anyway then we could define the
$h->get_info method to support either.
> If the constants are in a separate module, they have to write:
>
> use DBI::Const qw( :GetInfo )
>
> Or is
>
> use DBI qw(...)
>
> the ultimate goal?
I don't see a benefit in creating an 'aribitrary' split in where
constants come from from the users point of view. (The DBI can
perform the same magic behind the scenes.)
> Whatever you prefer, it's likely that we need a special import()
> method, especially if the constants are implemented as hash values.
Yeap. Though you could argue that using hash fetching should be the
primary API to get_info and just not bother supporting importing
numeric constants. And I don't think there's a good performance
argument for numeric constants. So lets just skip the import :)
Tim.
