[web2py] Re: Capturing field changes with _after_update and smartgrid
Why not just use before_update? On Friday, November 9, 2012 10:53:21 AM UTC-7, Jim S wrote: I'm missing something. I have a table where I want to react to changes to a particular field. I'm trying to use the _after_update callback check for this. However, using this it appears to me that I am only seeing the data values after the update. I can't see what they were before the update so I don't know which fields we actually updated. Is there a 'bef'ore' buffer available that I'm missing? I'm trying to capture changes made using a smartgrid. Any tips would be appreciated. -Jim --
[web2py] Re: Capturing field changes with _after_update and smartgrid
Because the update may fail. -Jim On Friday, November 9, 2012 12:20:18 PM UTC-6, Derek wrote: Why not just use before_update? On Friday, November 9, 2012 10:53:21 AM UTC-7, Jim S wrote: I'm missing something. I have a table where I want to react to changes to a particular field. I'm trying to use the _after_update callback check for this. However, using this it appears to me that I am only seeing the data values after the update. I can't see what they were before the update so I don't know which fields we actually updated. Is there a 'bef'ore' buffer available that I'm missing? I'm trying to capture changes made using a smartgrid. Any tips would be appreciated. -Jim --
[web2py] Re: Capturing field changes with _after_update and smartgrid
Use before_update to store the current data in the session, then the after_update would have access to it. On Friday, November 9, 2012 11:55:36 AM UTC-7, Jim S wrote: Because the update may fail. -Jim On Friday, November 9, 2012 12:20:18 PM UTC-6, Derek wrote: Why not just use before_update? On Friday, November 9, 2012 10:53:21 AM UTC-7, Jim S wrote: I'm missing something. I have a table where I want to react to changes to a particular field. I'm trying to use the _after_update callback check for this. However, using this it appears to me that I am only seeing the data values after the update. I can't see what they were before the update so I don't know which fields we actually updated. Is there a 'bef'ore' buffer available that I'm missing? I'm trying to capture changes made using a smartgrid. Any tips would be appreciated. -Jim --
Re: [web2py] Re: Capturing field changes with _after_update and smartgrid
I thought of that too, but for some reason it appears to be a fragile solution in my mind. Should I be putting more faith in the stack? Is this something that is commonly done? -Jim On Fri, Nov 9, 2012 at 1:39 PM, Derek sp1d...@gmail.com wrote: Use before_update to store the current data in the session, then the after_update would have access to it. On Friday, November 9, 2012 11:55:36 AM UTC-7, Jim S wrote: Because the update may fail. -Jim On Friday, November 9, 2012 12:20:18 PM UTC-6, Derek wrote: Why not just use before_update? On Friday, November 9, 2012 10:53:21 AM UTC-7, Jim S wrote: I'm missing something. I have a table where I want to react to changes to a particular field. I'm trying to use the _after_update callback check for this. However, using this it appears to me that I am only seeing the data values after the update. I can't see what they were before the update so I don't know which fields we actually updated. Is there a 'bef'ore' buffer available that I'm missing? I'm trying to capture changes made using a smartgrid. Any tips would be appreciated. -Jim -- --
Re: [web2py] Re: Capturing field changes with _after_update and smartgrid
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) --
Re: [web2py] Re: Capturing field changes with _after_update and smartgrid
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) -- --
Re: [web2py] Re: Capturing field changes with _after_update and smartgrid
Just reporting back. The _before_update is working perfectly for me. -Jim On Fri, Nov 9, 2012 at 3:45 PM, Jim Steil ato.st...@gmail.com 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 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) -- --
Re: [web2py] Re: Capturing field changes with _after_update and smartgrid
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) -- --
