Thanks, Anthony - forgot about the _after_update callback. Could you please
clarify how to use it in this situation? I was trying this:
def create_after_update_callback(self, db, id):
def update_mytable1_record(s, f, id):
if not db(db.auth_user.id ==
id).is_active:
# perform updates on table
db.auth_user._after_update.append(lambda s, f:
update_mytable1_record(s=s, f=f, id = id))
Any attempts to select()/inspect the table row being "deleted", whether
through the set object (s) or the auth_user table, result in a "list index
out of range" error (I guess I can't access the object as a result of
is_active being set to False?).
On Monday, June 10, 2013 10:31:24 PM UTC-5, Anthony wrote:
>
> Can you use the _after_update callback instead?
>
> On Monday, June 10, 2013 5:32:12 PM UTC-4, Lamps902 wrote:
>>
>> When enable_record_versioning is being utilized, db rows aren't actually
>> deleted, but the "is_active" bit is flipped off instead. As far as I can
>> tell, this means that the _after_delete callback for a given table won't be
>> called, which is problematic when you are using this callback to
>> delete/flip off 'is active' bits of associated rows in other tables. Is
>> there any convenient way around this, or will it simply be necessary to
>> forgo the callback, and flip the "is_active" bit of associated records in
>> other tables manually by performing an update() when deleting a record?
>>
>
--
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
