[Dbix-class] Unexpected behavior with possible NULL foreign key relationship

[Matt S Trout]

On Thu, Aug 07, 2008 at 02:08:54PM -0500, mike wrote:
> i'm bringing this issue back up, as i've had time to look at it again.
>  first, some context:
> 
> On Fri, Mar 21, 2008 at 03:14:40PM -0700, Damon Snyder wrote:
> > Hi Everyone,
> > I'm new to the list so bear with me if I'm missing something. I have a
> > foreign key relationship where it's possible that the belongs_to
> > relationship is NULL. See the classes below. When I create a new
> > Smsmessage object e.g. like so:
> 
> [snip]
> 
> >> >  On Wed, Apr 2, 2008 at 3:52 PM, mike <pulsation at gmail.com> wrote:
> >> however, this current problem is not mysql.  i have confirmed that it
> >> only occurs
> >> on newly created objects by adding a call to discard_changes after the creation.
> >> following is the modified patch including the test that illustrates
> >> this behavior.
> >
> > (1) your mail client mangled the patch
> > (2) after unmangling it, it makes 60core and 91debug fail.
> >
> > Can I have another patch that doesn't break anything else please? :)
> 
> attached you will find my modified patch, produced against 0.08 trunk
> (r4736).  if only by virtue of being an attachment, it should not have
> been mangled by gmail or this unholy fvwm->rdesktop->win32->firefox
> setup i use.
> 
> i've been perusing around the innards, but i'm not sure where the issue
> is.  the field is not specified to create(), so Row's constructor is not
> calling store_column for it.  if the field is specified, the accessor
> returns undef, as expected.  however, if the field is not specified, the
> accessor returns an object that describes a row from that table.  if the
> table is empty, the accessor returns undef.
> 
> if the table contains multiple rows, we see the warning:
> 
> 	DBICTest::Schema::CD::genre(): Query returned more than one row.
> 	SQL that returns multiple rows is DEPRECATED for ->find and ->single
> 
> it appears that the search_related that is called performs a simple
> SELECT * FROM table.  on lib/DBIx/Class/Relationship/Accessor.pm:21-33:
> 
>     $meth{$rel} = sub {
>       my $self = shift;
>       if (@_) {
>         $self->set_from_related($rel, @_);
>         return $self->{_relationship_data}{$rel} = $_[0];
>       } elsif (exists $self->{_relationship_data}{$rel}) {
>         return $self->{_relationship_data}{$rel};
>       } else {
>         my $val = $self->find_related($rel, {}, {}); # <-- performs
> unconditional search??
>         return unless $val;
>         return $self->{_relationship_data}{$rel} = $val;
>       }
>     };
> 
> also attached you will find a patch to lib/DBIx/Class/Row.pm that fixes
> this problem

No it doesn't.

Well, it fails to fix the underlying cause.

Actual fix is http://dev.catalyst.perl.org/svnweb/bast/revision/?rev=4773

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/