[CDBI] Re: Disabling cascading before_update/after_update triggers
andrewo at oriel.com.au
Wed Oct 18 05:53:13 BST 2006
> 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->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
More information about the ClassDBI