Re: Autovivified column data after before_create trigger

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

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) ?

> 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 happyto 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 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.

Tim.