Re: Autovivified column data after before_create trigger

[prev] [thread] [next] [Date index for 2004/10/12]

Tim Bunce wrote:

>On Mon, Oct 11, 2004 at 04:41:27PM -0500, Christopher L. Everett wrote:
>  
>
>>As far as I can tell, for every column you set a constraint on, a null 
>>entry in the instance data gets created for every column you don't 
>>explicitly set.
>>
>>For example, a table having DDL like this:
>>
>>CREATE TABLE bar(
>>  bar_id integer unsigned auto_increment primary key,
>>  baz integer unsigned NOT NULL,
>>  quux integer unsigned NOT NULL
>>);
>>
>>(note the NOT NULLs) with a class like
>>
>>package Foo:Bar;
>>use base 'Foo::Base';
>>
>>__PACKAGE__->table('foo.bar');
>>__PACKAGE__->columns(All => qw/bar_id baz quux/);
>>
>>__PACKAGE__->add_constraint($_ => &is_def) foreach qw/baz quux/;
>>    
>>
>Shouldn't that be ($_ => \&is_def) ?
>  
>
Yes it should ... I wrote the above as a simple test case for the post.

>>my $bar = Foo::Bar->create({baz => 1});
>>
>>leaves your object data like this after the before_create trigger runs:
>>
>>bless({baz => 1, quux => undef}, Foo::Bar);
>>    
>>
>>IMO, the proble with the included patch is that I shouldn't have to do
>>this work at all -- oughtn't the constraint checking be run against a 
>>local copy of the object?  In the limited time that I have, I couldn't
>>find out how the constraint checking happens in before_create, but if
>>helps me out  bit, I will be more than happy to produce a permanent fix
>>and a set of tests, because forgetting to check for this problem will
>>cost me a lot more than the time it takes me to fix it for good.
>>    
>>
>Stepping through the code with a debugger, starting at the create() call,
>should help find the spot where the extra field is getting added.
>  
>
I know for a fact that the problem occurs during the before_create trigger,
because of print statements

>I don't have time to set the up and do it, but I couldn't see a cause
>just by reading the code. add_constraint adds a before_set_$column
>trigger but, as far as I can see, that's not invoked by validate_column_values
>unless that column exists in the hash.
>  
>
Yeah, it's not obvious where it crops up.  I have a current project on 
urgent
status, when I'm done w/ that I'll step though it with a debugger.

        -- 
        Christopher L. Everett

Chief Technology Officer                               www.medbanner.com
MedBanner, Inc.                                          www.physemp.com