Peter Harkins wrote: >I can see why folks would want this, but I'd like to toss in a vote >against it being on by default. > I just started to write the same thing :-)
> It strikes me as spooky action at a >distance -- because another process possibly on another machine saved >the state of one of its objects, the objects in my current script start >tossing exceptions or quietly changing their state. > I know 3 common ways dealing with this problem: - Last write wins (which we have now) - Validating on save. You get an object, process it, try to save and - bang - "data was modified by someone since you last read it, would you like to loose your changes"? This is a cheap way but works only with user interaction and this is unacceptable in most cases since users usually don't like to debug you system. - Locking for writing. If you plan to modify an object you lock it exclusively and other processes wait for you. This affects performance on checks "if locked" and on waits for update time that now includes all the cycle read-process-update of the updater. So the first option is not only viable it's actually better in many cases (because it's fastest). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
