Re: Deleting an object on the other side of a has_a

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

William McKee wrote:

>That's an interesting design that I've never seen. What's the reason for
>cross-linking the tables like that?
>
Well, the two objects do refer to each other.  ClassA has zero or one 
instances of ClassB, and ClassB always belongs to exactly one ClassA.  
It's true that I don't need foreign keys in both tables (indeed now I 
don't), but I never really thought of it as a problem.  Actually, I 
didn't think much at all ;)

Now that I describe it like that, perhaps I did want a might_have after 
all, hehe.


> I've been using a has_many
>relationship and retrieving all the TableB objects that match my TableA
>id as described in my previous post. Is there some advantage you gain by
>cross-linking like this?
>  
>
Performance?  I dunno really, it was more of a mistake than a design 
decision, I'm afraid!


>Are you storing these objects in global variables? If not, it seems to
>me that CDBI should safely release them unless the processes are running
>simultaneously and you are witnessing concurrency issues.
>  
>
Well, I'd have thought so too.  I'll try and get round to making a test 
case over the weekend.


>So do you still have two has_a relationships setup in your CDBI classes
>or did you remove one?
>  
>
Removed one, and did the following in ClassB:

sub my_a {
    my $self = shift;

    my @list_of_a = ClassA->search (my_b => $self->id);

    # there should only be one.
    die sprintf "More than one object of ClassA points at ClassB %s", 
$self->id
        unless (@list_of_a == 1);

    return $list_of_a[0];
}