[Dbix-class] Relations on non in_storage rows (my todays gotcha)

[Jess Robinson]

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