Michael Peppler wrote:
On Tue, 2004-08-10 at 17:42, H.Merijn Brand wrote:
On Tue 10 Aug 2004 00:52, Tim Bunce <[EMAIL PROTECTED]> wrote:
Comments welcome.
=head1 DBI ROAD-MAP
9th August 2004
This document aims to provide a high level overview of the future direction of the DBI.
It outlines the broad categories of changes, along with some rational, but does not go into implementation details and ignores many more minor planned enhancements. More details can be found in:
http://svn.perl.org/modules/dbi/trunk/ToDo
(username guest, password guest)
Unsure if this is the right spot, but in writing the DBD I found the unidirection from handle to handle quite restrictive.
Statement handles know what database handle they belong to, but database handles don't know what statement handles are opened on them.
I had the same issues when adding the bulk-copy functionality to DBD::Sybase. For now I'm storing a pointer to the imp_sth_t in the dbh with the understanding that this is *only* used in that particular situation - but it's not really satisfactory... :-)
DBD::Informix has always implemented things so that the $drh has a list of the $dbh that have been opened on it, and each $dbh has a list of the $sth that have been created on it. But I don't particularly like having to do it -- it seems perfectly obvious to me (but I'm not Tim) that the $dbh should keep such a track so that whenever a $dbh is destroyed, all the associated $sth can be destroyed first.
Someone has logged a bug against DBD::Informix because it wasn't cleaning up properly as a handle was destroyed. It turns out that the statement-level active flag was not set. But, simply setting it on means DBD::Informix runs foul of all sorts of issues during destroy. Of course it's a bug that it isn't set on; but having it set on leads to some very odd (core dumping) behaviour.
--
Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) #include <disclaimer.h>
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
