[Dbix-class] DBIx::Class 0.08100 released to CPAN

[Peter Rabbitson]

David Ihnen wrote:
> John Napiorkowski wrote:
>>
>> --- On Mon, 4/20/09, David Ihnen <davidi at norchemlab.com> wrote:
>>
>>   
>>> From: David Ihnen <davidi at norchemlab.com>
>>> Subject: Re: [Dbix-class] DBIx::Class 0.08100 released to CPAN
>>> To: "Class user and developer list" <dbix-class at lists.scsys.co.uk>
>>> Date: Monday, April 20, 2009, 6:18 PM
>>>
>>>
>>>
>>>   
>>>
>>>  
>>> Okay, I have a question playing with this release.
>>>
>>>
>>>
>>> We have observed that if you attempt to create-related a
>>> new row in a
>>> table that has a belongs-to to a third table - and omit the
>>> hash entry
>>> for the relationship column id in question entirely - we
>>> get an error:
>>>
>>>
>>>
>>> DBIx::Class::Relationship::Accessor::__ANON__():
>>> Column
>>> donor_id not loaded or not passed to new() prior to
>>> insert() on
>>> DB::Schema::ivr_schedule=HASH(0x7f895b9c72e8) trying to
>>> resolve
>>> relationship (maybe you forgot to call
>>> ->reload_from_storage to get
>>> defaults from the db) at
>>> /var/www/samp/DB/Schema/ivr_schedule.pm line
>>> 345
>>>
>>>
>>>
>>> BUT - if we *do* put the hash entry in for the relationship
>>> tying
>>> column (donor_id in this case) - but leave its value
>>> undefined - the
>>> error does not occur.
>>>
>>>
>>>
>>> What do you make of that?
>>>
>>>
>>>
>>> David Ihnen
>>>
>>>
>>>     
>>
>> I noticed something similar when playing with MojoMojo, but didn't think I could consider it a bug.  What I found was that if you do create on a source with a column that is allowed to be null and you don't pass the column explicitly as undef value, when you do get_columns on it (that is the object returned by ->create) , that column is missing.  Doing ->reload_from_storage after create fixes it, since that will force a reload from the database, and the column is properly setup as undef. Hence the message.
>>   
> So 'does not exist' is not equivalent to 'undef' per the logic in the
> code?  Does something break if they are equivalent?

http://search.cpan.org/~mstrout/DBIx-Class-0.08100/lib/DBIx/Class/Row.pm#new

'does not exist' = I don't know
'undef' = There isn't one

>> So my question to you is if this relationship is allowed to be null?  
> Yes, several points in our schema have multi-way connections - a table
> can point to either A or B or C (like in this case a schedule that can
> be attached to three different types of objects)  So this table is
> allowed to have null values on these rows.  Curiously - the donor table
> gave the result but the group table did not.  We were unable to
> determine any difference in the configuration of the classes between the
> two relationships.

Off the top of my head this *might* be related to:
http://search.cpan.org/~mstrout/DBIx-Class-0.08100/lib/DBIx/Class/Relationship.pm#belongs_to
(look at the bottom, discussion of undef_on_null_fk). If this is indeed
the cause, we need to fix things up so the behavior is uniform.