atom feed23 messages in org.perl.dbi-devRe: Handle Creation with new_child()
FromSent OnAttachments
David WheelerJan 31, 2005 10:28 pm 
Tim BunceFeb 1, 2005 2:43 am 
David WheelerFeb 1, 2005 9:16 am 
Tim BunceFeb 2, 2005 2:58 am 
David WheelerFeb 2, 2005 10:49 am 
David WheelerFeb 2, 2005 10:57 am 
Tim BunceFeb 3, 2005 7:44 am 
David WheelerFeb 3, 2005 8:40 am 
Tim BunceFeb 3, 2005 3:30 pm 
David WheelerFeb 3, 2005 3:48 pm 
Tim BunceFeb 4, 2005 2:07 am 
David WheelerFeb 4, 2005 10:38 am 
Sheikin SergeiFeb 4, 2005 11:31 am 
Michael A ChaseFeb 4, 2005 12:22 pm 
David WheelerFeb 11, 2005 11:18 am 
Tim BunceFeb 12, 2005 10:11 am 
David WheelerFeb 12, 2005 4:35 pm 
Tim BunceFeb 13, 2005 2:44 pm 
David WheelerFeb 13, 2005 5:54 pm 
Tim BunceFeb 14, 2005 3:09 am 
David WheelerFeb 15, 2005 10:37 am 
Tim BunceFeb 15, 2005 2:21 pm 
David WheelerFeb 15, 2005 9:01 pm 
Subject:Re: Handle Creation with new_child()
From:Tim Bunce (Tim.@pobox.com)
Date:Feb 14, 2005 3:09:10 am
List:org.perl.dbi-dev

On Sun, Feb 13, 2005 at 05:54:40PM -0800, David Wheeler wrote:

On Feb 13, 2005, at 2:44 PM, Tim Bunce wrote:

The DBD::_::connect method then becomes just something like

my $dbh = $drh->new_child($attr) or return; $dbh->connect(...) or return; return $dbh;

then we kindly ask driver authors to remove their DBD::foo::dr::connect method (so the DBI's default one get used) and implement most of the logic in a new DBD::foo::db::connect method instead.

(The same applies to DBD::foo::db::prepare.)

That sounds fairly straight-forward for them. Generally, it would just involve moving connect() to a different package, yes?

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.]

One way would be to have the driver provide a DBI version compatibility value. If set to high enough version then the DBI's (internal) load_driver method would delete DBD::foo::dr::connect if DBD::foo::db::connect exists.

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 :)

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.

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.

Tim.