Cool, I might have suggested using versioning if all you are trying to do 
is to track changes.

On Friday, November 9, 2012 3:38:28 PM UTC-7, Jim S wrote:
>
> Just reporting back.  The _before_update is working perfectly for me.
>
> -Jim
>
>
> On Fri, Nov 9, 2012 at 3:45 PM, Jim Steil <ato....@gmail.com <javascript:>
> > 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 <nip...@gmail.com 
>> <javascript:>>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")
>>>
>>> -- 
>>>  
>>>  
>>>  
>>>
>>
>>
>

-- 



Reply via email to