in reply to The importance of context in debugging
And later in my code tried to do something like this:package YV::Table::ArticleAuthor; use base 'YV::Table::DBI'; __PACKAGE__->table('article_authors'); __PACKAGE__->columns(All => qw/author_id article_id/); __PACKAGE__->hasa(YV::Table::Author => 'author_id'); __PACKAGE__->hasa(YV::Table::Article => 'article_id'); # other methods
Guess what happened next from here?use YV::Table::ArticleAuthor; # this is built dynamically... my %delete_article_xref = ( 23 => 1, ); # $author is an YV::Table::Author object initialized prior.. my @author_articles = YV::Table::ArticleAuthor->search(author_id => $a +uthor->id); # delete cross reference for $author and article id # (In affect, I want to 'disassociate' article with $article_id from t +he $author) for (@author_articles) { next unless $delete_article_xref{$_->article_id}; $_[0]->delete(); }
|
As a result of invoking the delete() method on an instance of the YV::Table::ArticleAuthor object, I removed all article to author associations. That is, not just one article from a single (selected) author. This caused a little havoc with a web tool I wrote..
The actual problem rested with my lack of understanding how Class::DBI worked. Looking back at the documentation, I figured that the reason the delete() method was acting so 'strangely' was because the primary column of the YV::Table::ArticleAuthor class was in fact author_id and delete() uses this very column to construct (or rather 'restrict') it's DELETE SQL. So the quick fix to my problem was to swap the fields like so: And since the first column is (by default) taken to be the primary column, delete worked as I wanted it to thereafter. ;-). |
# Under Construction
|
|---|