Re: FW: many to many help

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

Take this with a grain (or 10) of salt, because I have not looked at 
your code in detail, but this may apply. I found (in 0.95) that using a 
link table to link a table back to itself caused some problems because 
of the way it looked up relationships. If two columns both inflated to 
the same object type, only the first one would be found, and this messed 
up all kinds of things that I can't recall now.

I had a table "Node" that stored My::Node's, and table "Relation" that 
stored My::NodeRelation's, which related Nodes to each other. My 
solution was to create an empty subclass of My::Node called 
My::RelatedNode. Then declare

My::NodeRelation->has_a( node1 => 'My::Node');
My::NodeRelation->has_a( node2 => 'My::RelatedNode');

The objects are effectively identical, but because they belong to 
different classes the lookups were not short-circuited when it got to 
the first Node in the relation. (And happily 
$related_node->isa("My::Node") still is true :)

Of course all this may have changed in 0.96, I haven't looked at it yet. 
Anyway, it's a thought that might be worth chewing on. Good luck.

-Vince


Bruner, Todd wrote:

>OK, I now know that the XYZ::Links needs to be before XYZ::Things if they
>are in the same file.  However, I still run into a problem with cascading
>delete.  Namely, as coded below, the cascading delete will only delete the
>rows in the Links table with srcThingId = to target, and ignores rows in the
>Links table with dstThingId = to target.
>Reversing the order of the has_a declarations in the XYZ::Links package,
>reverse the column that is matched (ie. dstThingId now is matched instead of
>srcThingId).  Any pointers or clues to how to make this work will be
>appreciated.  
>
>Todd
>
>
>
>-----Original Message-----
>From: tbruner@xxxxxx.xxx [mailto:tbruner@xxxxxx.xxx] 
>Sent: Monday, June 07, 2004 8:40 AM
>To: cdbi-talk@xxxxxx.xxxxx.xxx
>Subject: many to many help
>
>
>After reading the docs and scanning this lists archives, I am left wondering
>how to accomplish the following.  
>
>Database schema: (unessential columns omitted for brevity)
>
>create table Things (
>     ThingId integer unsigned not NULL auto_increment,
>     node    varchar(80),
>     ...
>     primary key(ThingId)
>);
>
>create table Links (
>     LinkId  integer unsigned not NULL auto_increment,
>     linklable varchar(80),
>     srcThingId integer unsigned,
>     dstThingId integer unsigned,
>     primary key (LinkId)
>);
>
>The idea for the database is to track the relationship between a set of
>"Things."
>
>I have the following set up in a package:
>
>package XYZ::DB;
>use base qw(Class::DBI);
>use warnings;
>XYZ::DBI->connection(connection_details_omitted);
>
>package XYZ::Things;
>use base qw(XYZ::DB);
>XYZ::Things->table('Things'); XYZ::Things->columns(All=>qw(ThingId node));
>XYZ::Things->has_many(links => 'XYZ::Links');
>
>package XYZ::Links;
>use base qw(XYZ::DB);
>XYZ::Links->table('Links');
>XYZ::Links->columns(All=>qw(LinkId linklable srcThingId dstThingId));
>XYZ::Links->has_a(srcThingId => 'XYZ::Things'); XYZ::Links->has_a(dstThingId
>=> 'XYZ::Things');
>
>Now in my program I am trying to delete a thing using the following:
>
>my $obj = XYZ::Things->retrieve("7"); # get ThingId = 7, which exists in DB
>$obj->delete;
>
>When that snippet runs, I get the following error:
>
>things is not a column of XYZ::Links at
>/usr/local/libdata/perl5/site_perl/Class/DBI/Relationship/HasMany.pm line 61
>
>Can anyone shed some light on what I'm doing wrong?  Any help will be
>appreciated.
>
>Thanks in advance,
>Todd
>
>  
>