Ruby on Rails

On Wed, Mar 30, 2011 at 5:59 PM, Ramon Leon <ramon.leon@allresnet.com> wrote:

> On 03/30/2011 02:26 AM, Xavier Noria wrote:
>>
>> Perhaps you know it, but in web programming "the last edit wins" is a
>> meaningful rule that allows you to get rid of these controls. If two
>> people edit the same form, the last received data is the one that
>> prevails, it doesn't matter who requested the form first.
>
> That's a horrible rule and a great way to lose data.  The correct rule is
> the first edit wins.  The last one fails and must refresh his view and try
> again.  This is easily accomplished by using version numbers and failing any
> update where the version has changed since the initial view.

Nah, I don't think that's right. Versioning may make sense in some scenario
(as my comment implicitly acknowledged), but calling the rule above
"horrible" is denying the fact that it makes perfect sense in a lot of
use cases. Indeed it is the most common way to implement concurrency
handling: doing nothing because last wins is normally fine.

If user U says the state of a model is S, and user W says a
millisecond later that it is T, and the edition made by W does not
depend on the exact previous state of the model, then why you should
not believe W? He said it is T, so let it be T.

From the point of view of user U, he doesn't know whether the requests
were interleaved or sequential, and he does not care normally. All he
knows is that after he took a bit of coffee someone else edited the
same record and now it looks different.

If the edition does depend on the previous state, then you need to put
those extra controls.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.