|David Wheeler||Jan 31, 2005 10:28 pm|
|Tim Bunce||Feb 1, 2005 2:44 am|
|David Wheeler||Feb 1, 2005 9:16 am|
|Tim Bunce||Feb 2, 2005 2:59 am|
|David Wheeler||Feb 2, 2005 10:50 am|
|David Wheeler||Feb 2, 2005 10:58 am|
|Tim Bunce||Feb 3, 2005 7:45 am|
|David Wheeler||Feb 3, 2005 8:40 am|
|Tim Bunce||Feb 3, 2005 3:30 pm|
|David Wheeler||Feb 3, 2005 3:49 pm|
|Tim Bunce||Feb 4, 2005 2:08 am|
|David Wheeler||Feb 4, 2005 10:38 am|
|Sheikin Sergei||Feb 4, 2005 11:31 am|
|Michael A Chase||Feb 4, 2005 12:22 pm|
|David Wheeler||Feb 11, 2005 11:18 am|
|Tim Bunce||Feb 12, 2005 10:11 am|
|David Wheeler||Feb 12, 2005 4:35 pm|
|Tim Bunce||Feb 13, 2005 2:44 pm|
|David Wheeler||Feb 13, 2005 5:54 pm|
|Tim Bunce||Feb 14, 2005 3:09 am|
|David Wheeler||Feb 15, 2005 10:38 am|
|Tim Bunce||Feb 15, 2005 2:22 pm|
|David Wheeler||Feb 15, 2005 9:01 pm|
|Subject:||Re: Handle Creation with new_child()|
|From:||David Wheeler (dav...@kineticode.com)|
|Date:||Feb 13, 2005 5:54:40 pm|
On Feb 13, 2005, at 2:44 PM, Tim Bunce wrote:
So, I'm looking at your new_child() stuff, instead.
That's a much bigger can of worms! (And one that's hard to tell how deep it is before you really get into it. Driver migration issues may be painful, for example.)
No :) Having per-class new_child() method is just a simple repackaging of the existing DBI::new_dbh (_drh, _sth) functions. That much is simple, I think.
Right, that's where I was going.
Then add in the setting of attributes. Perhaps by calling a new set_attr(\%attr) method from within new_child().
Sure. The more factored out these things are, the easier it will be for driver authors and subclassers to change behaviors.
? And the modifying connect() and friends to use it, perhaps instead of the $connect_closure?
$connect_closure is only used by clone() DBI->connect and DBI->connect_cached don't need changing.
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?
Then we have to face the fact that driver authors will (naturally) want their drivers to be compatible with old versions of the DBI.
Right, that's the tricky bit.
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? :)
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