...can someone in this context talk to me where db transactoins do / could come into play?
Is this because rows are not tied up in transactions at every form display? Is Bill suggesting doing a "lightweight" version of this in the framework? What other alternatives are there? On Oct 15, 10:09 am, mdipierro <[EMAIL PROTECTED]> wrote: > The message above is in the wrong thread. Yes. This is a race > condition and it can happen. > > Massimo > > On Oct 15, 8:50 am, billf <[EMAIL PROTECTED]> wrote: > > > Please can you explain how the id mechanism prevents the problem that > > I describe. > > > User A selects record with id=99 that has the following columns/ > > values: "name" = "Massimo", "town" = "Chicago". > > > User B selects the same record, id=99, "name" = "Massimo", "town" = > > "Chicago". > > User B updates the name to "Massimo di Pierro", leaves "town" = > > "Chicago" and submits the form. > > The database is updated. > > > User A (on the form displayed prior to user B's action) updates the > > "town" to "New York" and submits the form. > > As the id is still 99, the database will be updated and the version on > > the database will be: > > id=99, name="Massimo", town="New York" > > > i.e. unknown to both users A and B, user B's action has been silently > > undone. I have just tested this again and it is what happens. > > > In my suggested solution, the new column (version or timestamp) would > > have been updated during user B's update and therefore would not match > > with the value submitted by user A allowing user A's update to fail > > and providing the opportunity to notify user A as to what had > > occurred. The purpose of the feature is not to prevent user A from > > updating the record - he/she just re-displays user B's values, changes > > them and submits - it is just to prevent user A doing it without > > knowing. > > > Bill > > > On Oct 15, 2:18 pm, mdipierro <[EMAIL PROTECTED]> wrote: > > > > Not True. > > > > There is a mechanism to prevent that. SQLFORM for update forms stores > > > the record id server side. If the use tampers with the form accepts > > > detects it. > > > > Massimo > > > > On Oct 15, 3:59 am, billf <[EMAIL PROTECTED]> wrote: > > > > > If a user knows the id of a record then, by default, there is nothing > > > > to stop them deleting a record from the database irrespective of the > > > > delete checkbox being displayed. For example: > > > > >http://my_server:my_port/my_application/my_controller/my_action?id=th... > > > > > I know this is unlikely but in a business situation it seems a bit > > > > lax. In SQLFORM, deleteable is just used to decide whether to create > > > > the checkbox or not. Perhaps it should be saved in the form or > > > > session and checked before actually deleting. > > > > > Bill --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
