Just reporting back. The _before_update is working perfectly for me. -Jim
On Fri, Nov 9, 2012 at 3:45 PM, Jim Steil <[email protected]> wrote: > 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 <[email protected]> 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") >> >> -- >> >> >> >> > > --
