David Ihnen wrote: > John Napiorkowski wrote: >> >> --- On Mon, 4/20/09, David Ihnen <[email protected]> wrote: >> >> >>> From: David Ihnen <[email protected]> >>> Subject: Re: [Dbix-class] DBIx::Class 0.08100 released to CPAN >>> To: "Class user and developer list" <[email protected]> >>> 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. _______________________________________________ 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]
