[Dbix-class] Finding by primary key and might_have

[Zbigniew Lukasiak]

On Fri, Feb 20, 2009 at 9:23 AM, Peter Rabbitson <rabbit+dbic at rabbit.us> wrote:
> Zbigniew Lukasiak wrote:
>> One more thing - this test fails:
>>
>> ok( $schema->resultset('CD')->find( {
>>             cdid => 1,
>>             liner_notes => {
>>                 'notes' => 'test note changed'
>>             },
>>         },
>>         { key => 'primary' }
>>     ),
>>     'CD found'
>> );
>>
>> The liner_notes are linked to the CD by the CD's primary key (as a
>> might_have relationship) - so this specifies the key in two
>> conflicting ways - one by explicite parameter and one inferred from
>> the relationship.  The effect is this SQL:
>>
>> SELECT me.cdid, me.artist, me.title, me.year, me.genreid,
>> me.single_track FROM cd me WHERE ( me.cdid IS NULL )
>>
>> You can characterise that as a garbage in garbage out case - but I
>> think it is rather surprising and it can surface as another strange
>> case when composing find with other methods.
>>
>> A diff with the test against the trunk version is attached.
>>
>>
>> I hope you understand I am not doing that out of malice - I am just
>> testing my own library.
>>
>
> Afaik find() (and search() for that matter) were never designed to transcend
> relationships - you need to supply joins and all the shebang. I am inclined
> to call this a massive GIGO case, not worth investigating.
>
> Objections?

In my code I have already a workaround for that so I don't have any
interest in continuing but my understanding was that find should
ignore the additional hash keys (in that case with {key => primary}
those that are not in the primary key).  Here it does not.


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