Thanks Niphlid, I was going to ask about the db.commit issue before but forgot. I'm going to give the _before_update callback a try and see how well that works for me.
Thanks for all the responses, I truly appreciate it. -Jim On Fri, Nov 9, 2012 at 3:32 PM, Niphlod <niph...@gmail.com> wrote: > simple "scientific" thoughts. > It's like databases triggers. Db triggers apply to the "onupdate" event, > i.e. they let you use a set of just updated fields AND the fields that are > going to be updated. > Web2py has to intercept the update before or after, because databases (the > python dbapi in general) don't expose that functionality. I rely on > database triggers most of the times (as soon as I have access to the > underlying database), but that's just because for simple things I'm faster > on coding database triggers than python functions. > > However, with after_update, you can't "scientific-ly" know the values the > rows had before the update, because the update has "already happened". The > "stack" works (I have in production several apps relying on "web2py's > triggers"). After all, all your db(something).update() pass to the same > function that applies - conditionally - the triggers. > > PS: if the update fails, then the trigger fails too if you don't do a > db.commit() in the "trigger" itself. > All web2py's operations are handled in transactions, so it's "safe". > Moreover, all the before_* triggers have the "feature" that if that > function call returns "True" the update is not done.... kinda of an > additional validation (I use that in business logics, e.g., "you can't > delete the default mapping for a particular product category") > > -- > > > > --
