You are correct. I misspoke.
On Sep 23, 8:30 pm, Anthony <abasta...@gmail.com> wrote: > As I understand the term, use of detect_record_change is actually optimistic > locking. When User 1 loads an update form, User 2 can still read the > existing record and even load their own update form. However, if User 2 ends > up updating the record before User 1 submits the form, then User 1's form > submission will fail. Note, nothing is actually locked at the database level > -- this is all done via SQLFORM (hence still a small possibility of a race > condition). > > Anthony > > > > On Friday, September 23, 2011 7:34:43 PM UTC-4, Cliff wrote: > > > That would be a way to do pessimistic locking. > > > Of course I'm assuming DAL uses optimistic locking as it is sufficient > > 99% of the time. > > > On Sep 23, 5:39 pm, Anthony <abas...@gmail.com> wrote: > > > You can also do: > > > > form.accepts(..., detect_record_change=True) > > > > and the update will fail if the record has changed in the DB since the > > form > > > was originally loaded (the original record is hashed and used as the > > formkey > > > and then compared to the DB record again right before update -- I suppose > > > > there's still a slight chance of a race condition). In this case, your > > > method is probably better because different users would be updating > > > different fields, so no reason to force a failure. > > > > Anthony > > > > On Friday, September 23, 2011 5:14:01 PM UTC-4, Alex wrote: > > > > > thanks for the response! I already thought about using dbio=False > > > > parameter, with the update_record method this should now be quite > > > > easy. > > > > > explanation why it's important for me: in my scenario the auth_user > > > > table has many additional fields (address, bank account information, > > > > etc.), all these settings can only be changed by an admin user. only > > > > the password can be modified by the user itself. If both the admin and > > > > the user edit the same record at a time, the last one who saves it > > > > would overwrite the previous changes. If I only update the fields > > > > which are shown in the form then both users cannot overwrite the > > > > changes of each other. I'm also performing optimistic locking (with a > > > > version nr.) but in this case it is not necessary because both users > > > > modify different fields. > > > > > On 23 Sep., 22:13, DenesL <den...@yahoo.ca> wrote: > > > > > It is not a bug. Quoting the book: > > > > > When a Field is marked with writable=False, the field is not shown in > > > > > > create forms, and it is shown readonly in update forms. If a field is > > > > > > marked as writable=False and readable=False, then the field is not > > > > > shown at all, not even in update forms. > > > > > > This has nothing to do with the auto-(update, insert or delete) > > > > > operations performed by form.accepts > > > > > > To update only the setting1 field you can do: > > > > > > def edit1(): > > > > > id = request.args(0) > > > > > db.mytable.setting2.readable = db.mytable.setting2.writable = > > > > > False > > > > > row = db.mytable(id) > > > > > form=SQLFORM(db.mytable, row) > > > > > if form.accepts(request.vars, formname='mytable_form', > > > > > dbio=False): > > > > > row.update_record(**form.vars) > > > > > logger.debug(db._lastsql) > > > > > return dict(form=form) > > > > > > as explained in: > > > >http://web2py.com/book/default/chapter/07#SQLFORM-without-database-IO > > > > > > but it really makes no difference, except for some IO, the resulting > > > > > database record will be identical in both cases, so why bother?.
