On Feb 14, 2005, at 3:09 AM, Tim Bunce wrote:
Yes. That much should be trivial for them. The more tricky issue is that it affects how attributes are handles.
Currently the drivers connect() method can process the contents of \%attr directly. Many support connect() atributes that are not supported as handle attributes. In other words, currently:
$dbh = DBI->connect(..., { foo_bar => 42 }); # ok $dbh->{foo_bar} = 42; # not ok
With the new logic the attributes are all stored in the handle before the drivers connect method gets called. So drivers have to "go fishing" for all possible driver attributes relevant to the connnect and get the current values from the handle. Not a big deal, but definitely another change and scope for problems.
[On the roadmap/todo there's an item about recording the names of all attributes that have been set on a handle. That may also be useful here so drivers can be led by what attributes have actually been set rather than having to go check every possible attribute.]
Yes, that makes sense. Just an array reference somewhere listing them. Or perhaps keeping the original hash ref, at least for the duration of a call to connect()?
Yes, because then the DBI can leave it if there is no DBD::foo::db::connect, such as in older versions of the drivers. That doesn't sound so bad to me...am I insane? :)
Perhaps we both are :)
I'll drink to that!
Are you having fun yet? :)
I'm having a blast. I think I'll just implement my own handle caching code, for now, to prevent the resetting of AutoCommit which is, after all, all I need right now. But I'd be happy to help with the other projects so that I can eventually go back to using connect_cached
Sounds good to me! Thanks
I had only one method where I needed to prevent DBI from resetting AutoCommit (and PrintError, for that matter), so I've hacked in a way to cache the dbh just for the duration of that method call (which calls another, recursively called method). It's kind of ugly, but at least it's just ugly in one place, and I think that it better corresponds to DBI "best practices," anyway.
More generally, I'm very open to people volunteering to work on DBI enhancements from the roadmap/todo. Subversion branches make it easy for multiple people to be working on enhancements that scratch their own itches, without getting in the way of others or the mainline.
Feh. That's all I need is to be committer on yet another project. Me and my big mouth!
Regards,
David
