in reply to Re^9: method chaining fails where separate method calls succeed in DBIx::Simple (lifecycle)
in thread method chaining fails where separate method calls succeed in DBIx::Simple
Because destruction/disconnection related bugs can be hard to find
What is your opinion of DBIx::Connector? Do you think you
should delegate the complexity of keeping database connections alive
Also, please note well that destruction bugs and disconnection bugs
are two separate classes of problem. I dont know which the use of
double quotes about $db was supposed to address. But I do
know that common sense about reference counting between a DBIx::Simple
database handle and DBIx::Simple::Statement which has-a database
handle should not require any particular weakening like you are doing.
Just think for a second:
I simply dont understand why we need to prevent the reference count
from naturally increasing and decreasing as the DBIx::Simple instance
becomes a compononent of DBIx::Simple::Statement instances.
- we create a database connection, D
- we create a statement instance, S, which refers to D. This makes
the reference count for D== 2
- we create a another statement instance, S2, which also refers to D. This makes
the reference count for D== 3
- S2 goes out of scope. Reference count for D drops to 2
- S goes out of scope. Reference count for D drops to 1
- D goes out of scope, reference count for D drops to 0 and D is
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.
Without any concrete suggestions for modification, I dont know what
to say or try. But I would say this. Local::DBIx::Simple is a very
simple, clearly written wrapper and it isnt working.