|Do you know where your variables are?|
Re^9: method chaining fails where separate method calls succeed in DBIx::Simple (lifecycle)by Juerd (Abbot)
|on Aug 31, 2011 at 14:26 UTC||Need Help??|
DBIx::Simple goes to some significant lengths to make all DBIx::Simple::Statement objects suddenly become unusable as soon as their parent DBIx::Simple object is destroyed.
DBIx::Simple objects represent database connections, and when your connection to the database is gone, the corresponding statement handles will no longer function correctly. Because destruction/disconnection related bugs can be hard to find, DBIx::Simple actively shuts down the remaining active statements, and replaces them with objects that when used throw an error message that actually contains information about where the object was destroyed.
It is possible to build a DBIx::Simple object from an existing DBI connection, in which case destruction of the DBIx::Simple object does not cause disconnection. Whether statements should be kept around is debatable but I chose to keep it simple, and let DBIx::Simple clean its own mess regardless of how the database connection was originally made.
The option to pass an existing $dbh was added later and it appears that a part of the documentation was not updated accordingly:
Destroys (finishes) active statements and disconnects. Whenever the database object is destroyed, this happens automatically if DBIx::Simple handled the connection (i.e. you didn't use an existing DBI handle). After disconnecting, you can no longer use the database object or any of its result objects.Destruction used to unconditionally also disconnect the $dbh; this was changed later, but that made that last sentence incomplete. It should instead read "After disconnecting or destroying the DBIx::Simple object, ..."
Although the documentation should be improved, DBIx::Simple is doing exactly what it was designed to do. Indeed, simply removing the quotes and making a real reference does not fix a bug, and it is certainly not a wise thing to do: it introduces new bugs, because users of DBIx::Simple depend on their objects being destroyed and their database connections disconnected when their $db goes out of scope.
The trick for wrappers like metaperl's Local::DBIx::Simple could be to somehow keep a reference around and do some of their own lifecycle management.