billf: Ah, so you mean like transactions, but across several pages ? Generally I'd say that in that case it's the application's responsibility to ensure data consistency and handle overlapping user actions, but this will be hard to do in a web environment (the user may never actually submit the last page, can press the back button after the first page or leave without logging out, leaving your multi- page transaction locked).
vihang: There is no (change in the) response - when the query returns, the transaction locks have been already resolved. There can be a slight difference in behaviour depending on the type of the transaction isolation level, see http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html On Oct 15, 2:50 pm, vihang <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
