my understanding is that when a record is being modified/deleted, the transaction mechanism 'locks' the table. hence any other modification would fail or not get commited... only thing is that I do not know what kind of response is sent back..
On Oct 15, 5:39 pm, billf <[EMAIL PROTECTED]> wrote: > I believe that to achieve the same, a database transaction would have > to include both the select and the update/delete. This would include > the period of display, input and submission and the user may never > submit an update. I hope I'm correct in this understanding but please > correct if I'm not. > > The approach I am suggesting purely affects the update/delete sql > function and is intended as a light catch-all solution. > > Bill > > On Oct 15, 1:30 pm, achipa <[EMAIL PROTECTED]> wrote: > > > In what way is this different from database transactions ? > > > On Oct 15, 11: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 -~----------~----~----~----~------~----~------~--~---