Victor Ng wrote: > On 11/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Here you mean SELECT FOR UPDATE, right? > > No, I mean SELECT.
OK. Then another part of my answer is applied. > The use case is two users are viewing the same record, and they both > go to update the same record. Yes, this is the use case for the described method of avoiding long-lasting transactions and still garantee that only the intended information is modified. The method is not universal, since it does not give a user any garanteed time of data validity. This time is necessary to have for applications like sales. For that kind of application my first move would be to go for a stateful connection (https?). Next, a method of cleaning from overrun transactions is needed... > That means the view code would SELECT the records into the view. I'm > assuming you're doing SELECT FOR UPDATE and UPDATE on the POST > request/response cycle. If you're actually doing a SELECT FOR UPDATE > on the initial request, I can't see how you're holding on to your > connection between request response cycles. The assumption is correct. Can you still see any flaws in the sense that the user will not be informed that his action resulted in an attempt of altering a changed row? All the Django examples I saw suffer from these flaws in your example (or I misunderstand how Djando works). I concider the optimistic approch also good enough for most cases, and frankly I think it should be implemented by Django (and others) automagically, of course with a possibility to have it off. > vic Thanks for your comments! V.Chukharev --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
