achipa/vihang: I think you are both looking at more complex scenarios than I have in mind. I am not talking about multi-page transactions (in the sense of one user's transaction spanning several pages). I agree that would be the responsibility of the application.
The following, which I posted in another thread (see 'delete vulnerability?'), demonstrates the problem case. 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. To simply prevent the second update there is no need for additional complex transactions - just the addition of the proposed 'where' will prevent it. There is no transaction involved (although the update could, I think, be part of a transaction without causing a problem). Probably an underestimate but I reckon: 2 lines in SQLTable to conditionally add the column to a table. 10 lines in SQLFORM to save the column in self, conditionally show on form (like showid), check whether it has been tampered with (not really necessary - any changes to id and new columns could just be ignored as 'illegal') and include condition in update and delete statements. :-) Bill On Oct 15, 2:48 pm, achipa <[EMAIL PROTECTED]> wrote: > Upon further thought, wouldn't it be better to implement his in a > playback fashion ? I mean, you would handle the first pages like an > intentionally failed/rolled back transaction. The further the user > goes in the process, the further you get with the queries (and you > will notice any changes made by other users as then would influence > the selects). That way you have no locks, and only the final input of > the user does a commit, which is consistent, and requires no > additional columns. Am I right if I say this is basically a special > case of a multi-page form consistency problem ? > > On Oct 15, 3:22 pm, mdipierro <[EMAIL PROTECTED]> wrote: > > > I do not think belongs to web2py but it could be a next T2 feature. > > > Massimo > > > On Oct 15, 4:24 am, billf <[EMAIL PROTECTED]> wrote: > > > > I would like to request the ability to include a column in every table > > > to be used to avoid overlapping updates, i.e. where a record has been > > > updated by user B between user A selecting a record and updating/ > > > deleting it. When this occurs user B's updates are invisibly undone. > > > > I know that this can be hand-coded but I believe it would be a useful > > > and relatively minor addition to the core - as an option on > > > define_table? version=False being the default? > > > > The column could be either a version_number (simpler) or a > > > last_action_timestamp (perhaps more useful but more complicated?) and > > > would be used to prevent a record being updated/deleted if it had been > > > changed since selected. This could be achieved in SQLFORM.accepts() > > > by conditionally adding " and self.table.version==version" or similar > > > to the update and delete statements. The version (or timestamp) would > > > be handled in much the same way as 'id'. > > > > I accept that the probability of overlapping updates is small but in a > > > business situation it is important for web2py to be rigorous as > > > possible and this approach has negligible overhead. > > > > Do people think this is desirable, do-able or dumb? > > > > 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 -~----------~----~----~----~------~----~------~--~---
