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?
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 detail 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/[email protected]
_______________________________________________
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]
_______________________________________________
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]
