On Sun, 11 May 2008, Zbigniew Lukasiak wrote:
If you have a new object, not yet in the database, like:
$new_cd = $schema->resultset("CD")->new( {} );
Then if you call $new_cd->artist - this will return a first artist in
the 'artist' table.
So when writing code where you receive a DBIC row - and you don't know
where it comes from - you need to be carefull when calling relations
on it.
I wonder if this could be fixed by just returning 'undef' for 'single'
(and 'filtered'?) relations and '()' for 'multi' relations by the row
in such calls.
Looks like I missed this discussion initially (lazy me, not reading list).
From the followups, it seems it diverted off into what "search_related"
should do.. IMO search_related can find as many related things on NULL FK
column as it wants.. However just calling the belongs_to rel, or doing a
"find" should *NOT* return more than one, and only return one if there is
a non-null value in the FK column.
Can we separate those two out? (find_related and search_related).
I think one relying on the other is not sane in this case.. And would give
everyone what they were looking for.
I note that Zby's example was on a "new" object, which I wouldnt expect to
have any working rels at all.. But this also errors on an inserted object,
at least if one doesn't provide the FK value, and the DB defaults it to
NULL.
Jess
_______________________________________________
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]
