[Dbix-class] Bug? Failing test case for joining on default values

[Zbigniew Lukasiak]

On Tue, Nov 18, 2008 at 6:16 PM, J. Shirley <jshirley at gmail.com> wrote:
> My previous email was just the symptom, and after simplifying it I
> found the core problem.  Sometime since 0.08010 and trunk, behavior
> changed on the handling of default values after an object is inserted.
> The previous behavior wasn't actually correct, but my test case wasn't
> comprehensive enough yet to show the bug that was present in 0.08010.
>
> Imagine a single table that relates to itself with a default value
> ('name') that is part of the join condition (the full schema is in the
> attached patch).  Unless you specifically define the default value,
> DBIC trunk fails.  Here is a simplified example:
>
> With a relation defined like this:
> __PACKAGE__->has_many('selves', 'DBICTest::Schema::DefaultJoin',
>    {
>        'foreign.joinid' => 'self.joinid',
>        'foreign.name'   => 'self.name' # name has a default_value set
>    }
> );
>
>
> my $obj_1 = $schema->resultset("DefaultJoin")->create({ joinid => "1" });
> my $obj_2 = $schema->resultset("DefaultJoin")->create({ joinid => "1" });
> $obj_1->selves;
>
> # Fails with: DBICTest::Schema::DefaultJoin::selves(): Column name not
> loaded on DBICTest::DefaultJoin=HASH(0xb72e64) trying to resolve
> relationship at t/join_on_default_value.t line 20
>
> Now, this behavior is better than 0.08010 -- which just does the join
> without including 'name' at all in the relationship.  The query is
> simply:
>   SELECT COUNT( * ) FROM self_join me WHERE ( me.joinid = ? ): '1'
>
> If I assign 'name' the query and behavior (in both 0.08010 and trunk)
> is correct.
>
> The solution that I have now is to refetch via ->discard_changes and
> that solves the underlying problem.  I'm somewhat at a loss on what
> the proper way to solve it is, as the best idea is that when an object
> is defined inspect if a join condition is a default value and if so,
> automatically call ->discard_changes on the row after insert?
>
> Well, the first step is a failing test case, right?  It's attached,
> and let me know if you want me to commit.
>

This is again the recursion in insert (see my email about backcompat
and recursive insert).  I've tried this with my patch - but this time
I've changed the create method to run the non-recursive version of
insert and 5 of your tests passed.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/