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?
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[email protected]
