Peter Rabbitson wrote:
David Ihnen wrote:
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
Understood. We'll be more explicit.
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.
No, I don't think so. The foreign keys are specific single-column
references, not composite so some part can be null and some part not.
So here's the class definition that generates the error on donor
relationship when a client object method
->create_related('ivr_holiday', { holiday => date, description =>
$description });
is called. but does not create an error on groups when
->create_related('ivr_holiday', { holiday => date, description =>
$description, donor => undef });
is called.
package DB::Schema::ivr_holiday;
use base qw/DB::Schema/;
use strict;
__PACKAGE__->load_components(qw/DonorEvent PK::Auto DateTimeInflate Core/);
__PACKAGE__->table('ivr_holiday');
__PACKAGE__->add_columns('id');
__PACKAGE__->set_primary_key('id');
__PACKAGE__->add_columns(qw/client_id group_id donor_id description
must_call/);
__PACKAGE__->add_columns('holiday' => { data_type => 'date' });
__PACKAGE__->belongs_to(client => 'DB::Schema::client', { 'foreign.id'
=> 'self.client_id' }, { join_type => 'left' } );
__PACKAGE__->belongs_to(donor => 'DB::Schema::donor', { 'foreign.id'
=> 'self.donor_id' }, { join_type => 'left' } );
__PACKAGE__->belongs_to(groups => 'DB::Schema::groups', { 'foreign.id'
=> 'self.group_id' }, { join_type => 'left' } );
And here is the basic client object with the relationship used to create
defined here. (many other spammy relationships omitted for brevity)
package DB::Schema::client;
use DB::Schema::notice;
use base qw/DB::Schema/;
use strict;
use Carp;
use Data::Dumper;
__PACKAGE__->load_components(qw/PK::Auto Core/);
__PACKAGE__->table('client');
__PACKAGE__->add_columns('id');
__PACKAGE__->set_primary_key('id');
__PACKAGE__->add_columns(qw/code name short_name address address2 city
state zip lft rgt
phone ext contact email collection_site/);
__PACKAGE__->has_many(ivr_holiday =>
'DB::Schema::ivr_holiday' , 'client_id');
Maybe there's a semantic 'might belong to' that we don't have a
relationship description for?
David
_______________________________________________
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]
