RE: [CDBI] Re: Disabling cascading before_update/after_update triggers

> Andrew O'Brien wrote:
> > I had to extend the disabling triggers example on
> > http://wiki.class-dbi.com/wiki/Working_with_triggers to 
> allow me to only
> > disable the after_update trigger while I was in the 
> function call - all
> > other triggers had to remain functional.
> 
> I like what you did here, but isn't it unnecessary to disable 
> after_update triggers if you use __attribute_set() or
> __attribute_store() instead of set() in your trigger? That's
> what that wiki page says, right? I'm by no means a CDBI
> trigger expert...

Unfortunately not. The wiki doesn't really make sense in this case. From
the docs on _attribute_set:

"Updates values in the object via _attribute_store(), but also logs the
changes so that they are propagated to the database with the next
update. (Unlike set(), however, _attribute_set() will not trigger an
update if autoupdate is turned on.)"

So the sequence:

$o = Class->retrieve( $id );
$o->time();        # 60
$o->skill_level(); # 1.0
$o->total_time();  # 60
$o->skill_level( 1.5 );
$o->total_time;    # value of 90, as you would expect
$o->discard_changes;
$o->total_time;    # 60!

...will result in the class data being up to date but the data isn't
written through to the database. Autoupdate is on so the programmer's
assumption is that if a field is updated then it (and by extension any
derived fields via the trigger) are set in the DB.

A subsequent ->update will, of course, fix this but that is
counterintuitive as you only have to call ->update after making changes
to some columns but not others.

Easier to enforce the update by doing set() which also has the effect of
allowing all other constraint / whatever triggers to fire as normal for
the updated fields.

> > Is this useful to anyone and worth adding to the wiki?
> 
> Certainly! Concrete examples like this are very much worth 
> adding to the
> wiki.

Will do.

Cheers,

Andrew