yes, just catching up on threads; read the discussion there after posting here....
On Oct 15, 12:19 pm, mdipierro <[EMAIL PROTECTED]> wrote: > Please follow up any discussion on the other thread: > > Testing-the-water re change to update/delete > > yes, this is not related to transactions (I misunderstood the original > post). > In fact T2 now has the feature Bill suggested. > > On Oct 15, 12:15 pm, yarko <[EMAIL PROTECTED]> wrote: > > > ...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 -~----------~----~----~----~------~----~------~--~---
