Ruby on Rails

On 03/30/2011 11:20 AM, Xavier Noria wrote:
> 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.

I called your saying web apps are special and make last in the general
rule horrible.

Web apps aren't special, whether first or last edit wins is decided on
whether it's acceptable to lose data or not in a given situation
regardless of it being a web app or any other kind of app.

>Indeed it is the most common way to implement concurrency
> handling: doing nothing because last wins is normally fine.

That's not implementing concurrency handling, it's ignoring it.

> 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.

Because you don't know it was a millisecond later, it could have been 10
minutes later because user W sat there looking at the screen forever.
User U may have changed many fields on the model while user W just
updated one and you've now lost all of the data user U entered
effectively rolling back the record.

If that's acceptable, fine, last edit wins, however, for many if not
most business type objects, it's not OK.

>> 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.

Not just different, all of his work was lost because user W updated one
unrelated field. User U is now very pissed.

--
Ramon Leon

--
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.