might_have and Deep recursion error

[prev] [thread] [next] [Date index for 2004/09/29]

I have a design issue I'm hoping I can get a bit of advice on. I had set
up my basic classes, worked out a few complications and got everything
compiling fine. I started writing the test code but quickly ran into a
problem. When I tried to invoke $obj->update; on some of my objects, I
got:
Deep recursion on subroutine "Class::DBI::update" ...

And off the code wandered. I searched the docs, the wiki and the list
archives but didn't find any information. After some exploration, I
determined that the problem seems to be that the object I'm working on
was created from a lookup within another object, which has a might_have
relationship to the object I'm trying to update. The class definition
for that object has a might_have relationship to back to the table I
started with. Commenting out that definition in the class allows all the
tests to pass fine. Here's a quick example of the key code parts:
C<
_PACKAGE1_->might_have(foo => '_PACKAGE2_');
...
_PACKAGE2_->might_have(bar => '_PACKAGE1_');

(in test)
my $obj1 = _PACKAGE1_->retrieve(1);
my $obj2 = $obj1->foo;
$obj2->set(column => value);
$obj2->update; # this causes Deep recursion error
>

I use might_have in the production code to provide the relationship from
_PACKAGE2_ to _PACKAGE1_ because the relevant field is the primary key.
Changing the might_have to has_a (which sounds semantically more correct
anyway) does also prevent the error. However the docs say defining a
method on the primary key column with has_a is bad:
"*NOTE* You should not attempt to make your primary key column inflate
using has_a() as bad things will happen. If you have two tables which
share a primary key, consider using might_have() instead." 

So I used might_have - but that made bad things happen as well, lol.
Both packages need to have the classes define a relationship as both
will be the initial point of entry in different situations.

On the chance that the problem was caused because one object was created
from the first. So as a test I tried creating the object for _PACKAGE2_
from an independent retrieve, but the update still caused the same
error. ??!?

So, what's the canon for defining reciprocal relationships between
tables in the classes, or effecting look-ups starting in either object?
I'm just lazy enough to not want to have to remember that the
relationship $obj2 = $obj1->foo; works but $obj1 = $obj2->bar; doesn't.

Many thanks!

        -- 
        Sean Quinlan <seanq@xxxxxx.xx.xxx>
BMERC, Boston University