Tim Bunce wrote: > > On Fri, Nov 23, 2001 at 03:16:32PM +0100, Steffen Goeldner wrote: > > Tim Bunce wrote: > > (see <http:[EMAIL PROTECTED]/msg00499.html>) > > > > > > [And I'd ideally like to be able to detect and warn about misspelt > > > SQL_ attributes. And I'd also like to make it easy to map the names > > > into their official numbers (to make life easier for drivers, > > > especially DBD::ODBC). So I was thinking in terms of having the > > > DBI build process pre-process a list of all SQL_* GetInfo attributes > > > (and possibly *all* SQL_* macros) into some efficiently loadable form.] > > > > Recently, I extented the list of datatype codes for DBI, see: > > > > <http:[EMAIL PROTECTED]/msg00483.html> > > > > These constants are defined via ALIAS. I'm really not very familiar > > with XS, but if this is such an 'efficiently loadable form', then > > the same approach could be applied to the SQLGetInfo() constants: > > > > MODULE = DBI PACKAGE = DBI::Const::GetInfo > > > > I32 > > constant() > > PROTOTYPE: > > ALIAS: > > SQL_MAXIMUM_DRIVER_CONNECTIONS = SQL_MAXIMUM_DRIVER_CONNECTIONS > > SQL_MAXIMUM_CONCURRENT_ACTIVITIES = SQL_MAXIMUM_CONCURRENT_ACTIVITIES > > ... > > SQL_OJ_CAPABILITIES = SQL_OJ_CAPABILITIES > > CODE: > > RETVAL = ix; > > OUTPUT: > > RETVAL > > > > > > Or is this the wrong track? > > It could. The downside is more expensive DBI startup. >
How about a separate module, e.g. DBI::Const? It may contain an ordinary hash: our %DBI::Const::GetInfo = ( SQL_ACTIVE_CONNECTIONS => 0 ... , SQL_OJ_CAPABILITIES => 65003 ); Advantage: The load could be avoided or delayed. (I know, the downside is: It's not constant.) > > As you see, I prefer a separate namespace for SQLGetInfo() constants. > > Why? > > > > 1) I like namespaces ;-) > > Me too. Namespaces are good. > > > 2) I encountered some difficulties if namespaces are not preserved, > > see e.g.: > > <http:[EMAIL PROTECTED]/msg00538.html> > > 3) The requirement to list known constants is stated in > > DBI-1.20/ToDo: > > > > > Consider making all SQL_ known to the DBI. Want to check for > > > valid spelling. Also would like C<exists $h->{Attrib}> to > > > work. Maybe auto load a module that defines a private hash > > > that just serves to list known attributes. > > > Or DBI->SQL_FOO and/or DBI::SQL_FOO. > > > > With %DBI::Const::GetInfo::, we would have a hash for that > > purpose. > > > > Opinions? > > 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? Thus, we'll need something like: 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); } else { ... 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) 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 ... 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? Whatever you prefer, it's likely that we need a special import() method, especially if the constants are implemented as hash values. > > Driver code should naturally be written to use the numbers. > But users are _bound_ to use the $h->{SQL_FOO} form so there needs > to be an efficient mechanism to transparently convert the name to > a number. > > Tim. Steffen
