Re^10: method chaining fails where separate method calls succeed in DBIx::Simple (lifecycle)

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 to it?

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:

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 extinguished

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.

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.

Comment on Re^10: method chaining fails where separate method calls succeed in DBIx::Simple (lifecycle) Download Code

Replies are listed 'Best First'.
Re^11: method chaining fails where separate method calls succeed in DBIx::Simple (lifecycle) by Juerd (Abbot) on Aug 31, 2011 at 23:01 UTC
What is your opinion of DBIx::Connector? Do you think you should delegate the complexity of keeping database connections alive to it? It solves a different, unrelated problem. I'm not inclined to let DBIx::Simple depend on anything but DBI, except optionally. 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. I'm aware. Avoiding circular references has to do with avoiding problems regarding destruction; in particular, avoiding that destruction never happens during runtime. Because in DBIx::Simple, destruction causes disconnection (iff you let DBIx::Simple create the connection), I mentioned them together. 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. Common sense dictates that one does not use a circular reference if one can easily do without. There's no reason for ::Statement to have-a database handle, so it doesn't has-a one at all. All it needs is to refer to the object, as a hash key. That's a string. So all we need is that string. Et voila, we've avoided circular references without the complexity and risks of weakening. You're referring to the trick I'm using as "weakening" but it is very different. 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. tye has explained this thoroughly, with examples of what happens. I'm sorry, but if you don't understand his explanation, you don't understand destruction and you should really never use, or suggest that anyone use, a circular reference. But I would say this. Local::DBIx::Simple is a very simple, clearly written wrapper and it isnt working. It is working. I believe that the problem you encounter lies somewhere within the libraries you're using for object management, or, possibly, perl itself. In any case, the workaround is extremely simple and clear and you've already discovered it yourself: use a variable.	[reply]

Replies are listed 'Best First'.

Re^11: method chaining fails where separate method calls succeed in DBIx::Simple (lifecycle)
by Juerd (Abbot) on Aug 31, 2011 at 23:01 UTC

What is your opinion of DBIx::Connector? Do you think you should delegate the complexity of keeping database connections alive to it?

It solves a different, unrelated problem. I'm not inclined to let DBIx::Simple depend on anything but DBI, except optionally.

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.

I'm aware. Avoiding circular references has to do with avoiding problems regarding destruction; in particular, avoiding that destruction never happens during runtime. Because in DBIx::Simple, destruction causes disconnection (iff you let DBIx::Simple create the connection), I mentioned them together.

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.

Common sense dictates that one does not use a circular reference if one can easily do without. There's no reason for ::Statement to have-a database handle, so it doesn't has-a one at all. All it needs is to refer to the object, as a hash key. That's a string. So all we need is that string. Et voila, we've avoided circular references without the complexity and risks of weakening. You're referring to the trick I'm using as "weakening" but it is very different.

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.

tye has explained this thoroughly, with examples of what happens. I'm sorry, but if you don't understand his explanation, you don't understand destruction and you should really never use, or suggest that anyone use, a circular reference.

But I would say this. Local::DBIx::Simple is a very simple, clearly written wrapper and it isnt working.

It is working. I believe that the problem you encounter lies somewhere within the libraries you're using for object management, or, possibly, perl itself.

In any case, the workaround is extremely simple and clear and you've already discovered it yourself: use a variable.

[reply]