Re: has_a to non-CDBI objects

[prev] [thread] [next] [Date index for 2005/02/14]

--On February 14, 2005 10:35:18 AM +0000 Carl Johnstone 
<fade@xxxxxxxxxxx.xxxxx.xx.xx> wrote:
>
> Been playing around with a custom object that I want to expand a database
> column into. As far as I'm able to tell, CDBI will not update if I only
> make changes in this custom object.

That's true; CDBI doesn't know about any changes made outside it's classes. 
(Actually, it doesn't know about any changes made outside its API, but if 
one breaks encapsulation in one's code, caveat scriptor.)  Insofar as a 
CDBI class models a single database table, this behavior makes sense (to 
me), in the same way I wouldn't expect a trigger attached to table A to 
execute on modification of table B, even if one of A's columns was a 
foreign key into B, unless I'd told it to explicitly.  (I know that raises 
debate about various types of built-in constraint management; my little 
brain is happy with a simple model for now.)

> I've worked around it by using a couple of triggers in my CDBI object, -
> the first captures the stringified value of the column after loading, the
> second sets __Changed accordingly if it's different at the time I want to
> do the update:
>
> __PACKAGE__->add_trigger(
>   select => sub {
>     my $self = shift;
>     $self->{_init_scratchpad} = $self->scratchpad->_stringify;
>   },
>
>   before_update => sub {
>     my $self = shift;
>     $self->{__Changed}{scratchpad}++ if ( $self->{_init_scratchpad} ne
> $self->scratchpad->_stringify);
>   },
>
> );
>
> It would be nicer if this functionality was there by default, and worked
> in the is_changed (and any_changed) methods. I'd suggest the option of
> passing a is_changed method the same way you pass in your inflate/deflate
> methods. With the default being to do the same as above and store the
> initial deflated value for later comparison.

I think your solution is reasonable for the case where this sort of 
"active" examination of dependent objects is needed, but I'd hesitate to 
make it the default case; I'm not sure the overhead on every write is 
justified by the return in most cases.  Perhaps it might fit in well as a 
new type of relationship, say
Class::DBI::Relationship::HasSupervised or somesuch.

--
Regards,
Charles Bailey  < bailey _at_ newman _dot_ upenn _dot_ edu >
Newman Center at the University of Pennsylvania