Tim Bunce wrote:
Okay, but the recommended names are "db" and "database" (not "dbname").
Duh, s/dbname/database/g. (SQLite and Pg folks, are you listening?).
After the "dbi:AnyData:"; everything should be in "name=value;" format. So "dbi:AnyData:format=XML;table=Test;file=test.xml";
Ok, I thought one additional param was allowed, as long as I parse it out, but I'll change it. Some other DBDs do this with the database name, (e.g. ODBC with a named ODBC DSN) so should they also change this behaviour?
b. my $flags = {format=>'XML',table=>'Test',file=>'test.xml'}; $dbh=DBI->connect('dbi:AnyData:','','',$flags);
You've called it $flags but it's really \%attr
Yes, I should remember to call it that in the docs.
and the rules for attr are that driver private attributes should have a driver-specific prefix.
Yes, I know, and none get stored without prefixes. Since these are table-specific attributes, they are not stored directly in the database handle, rather under the $dbh->{ad_tables}->{$tablename} hash. I delete all of the lower-case attributes out of the \%attr in connect() and then feed them to ad_catalog() or ad_import() as appropriate (which put them in the ad_tables hash after munging). The few attributes that are not table-specific, I add the prefix before storing them back in $dbh. So all driver-private database handle attributes *do* have the prefix as soon as connect is done. Should I enforce the prefix in \%attr even though I just strip it out and do something else with the attributes?
On another topic: I am about to release a rather major interface change to Text::CSV_XS. Obviously it's not directly DBI but it does impact those who use Text::CSV_XS with other DBDs, should I post an RFC here, or in dbi-users, or not on the DBI lists at all?
-- Jeff
