0

I have a rails app where a particular form submit for a model is a two step process: on the first submit, the rails controller issues a render of a modal confirmation form, from which either the update action is invoked or the whole thing cancelled.

Rails optimistic locking seems like the answer here for dealing with out of date updates.

But for the user experience, if the Rails controller can compare the user A's model version against the current version without waiting until the update action to determine if the model is already out of date (due to user B updating the model in question concurrently), then another sort of view could be rendered indicating to user A that he needs to examine the updated model.

Are there any issues or gotchas associated with manually checking the :lock_version field in the controller and comparing it to the params[] version? Is there some built-in or "formal" way of doing this or should the controller just do the check explicitly?

Bogatyr
  • 19,255
  • 7
  • 59
  • 72

1 Answers1

0

I think the main issues with lock_version is that it's a one size fits all (i.e. you can't have different locks for different contexts) and that lock failure throws a stale object exception which is not particularly nice for the user.

Ryan Singer has presented an alternate approach that uses the updated_at timestamp in conjunction with validations to perform the check and then uses rails dirty tracking to show the user what changed. You can see it in the Rails Cast: http://railscasts.com/episodes/59-optimistic-locking-revised

I've been using this technique and am happy with it, although the example given doesn't cover the more complex cases where multiple models are involved in the action, or where you need to ensure model associations haven't changed as well etc.

Andrew Pietsch
  • 600
  • 5
  • 8