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

Tue Apr 21 02:42:26 GMT 2009

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=3DHASH(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 sou=
rce 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 objec=
t returned by ->create) , that column is missing.  Doing ->reload_from_stor=
age 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?

> 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.
> If so, this might be expected behavior.  If not, give us a bit more detai=
l in how your classes are created.
>   =

Will reload-from-storage run an additional query needlessly?
> BTW, I notice some people using ->discard_changes in place of reload_from=
_storage.  Please don't since this breaks replication support.  =

>   =

Aokay.

David

> John
>
>   =

>>
>>
>> Matt S Trout wrote:
>>
>>   After possibly the longest and most irritating
>> development cycle in DBIC's
>> history, 08100 is released!
>>
>> Important changes in this release are:
>>
>> - deploy() and Schema::Versioned are no longer experimental
>> - multi-create has been substantially rewritten and should
>> now work for
>>   as many cases as we've had thrown at us
>> - subselect support via SQL::Abstract 1.50 +
>> $rs->as_query
>> - InflateColumn::DateTime improvements for locale and
>> timezone support
>> - MRO::Compat usage to play nicer with perl5 v10
>> - txn_scope_guard is no longer experimental
>> - as/select hashref style for columns for easier
>> specification
>> - undef_on_null_fk for composite key relatoinships
>> - sqlt_deploy_hook callbacks can be assigned to the result
>> source rather than
>>   requiring a class method
>> - PostgreSQL array support
>> - new connect_info hashref-based argument style
>> - ON DELETE/ON UPDATE can be specified to the database
>> separately to row objects
>> - ON CASCADE DEFER can now be specified via is_deferable
>> - search_related_rs method added to resultsets
>> - replication support via Storage::DBI::Replicated
>>
>> plus a whole raft of bugfixes, as always.
>>
>> Thanks very much to ribasushi, arcanez, robkinyon, norbi,
>> ash, luke, and =

>> everybody else who contributed to this release, especially
>> the people who
>> did shitloads of stuff as well that I didn't mention by
>> name due to having
>> a memory like a sieve.
>>
>> As always, we look forward to comments, feedback, and all
>> the bug reports
>> you should have made already but haven't because you
>> didn't bother testing
>> the dev releases.
>>
>> mst, from the NPW http://enlightened.perl.org/
>> hackathon, signing off.
>>
>>   =

>>
>>
>>
>>  =

>>
>>
>> -----Inline Attachment Follows-----
>>
>> _______________________________________________
>> 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/dbix-class@lists.scsys=
.co.uk
>>     =

>
>
>       =

>
> _______________________________________________
> 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/dbix-class@lists.scsys.=
co.uk
>
>   =

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20090420/5d5=
b9349/attachment.htm