Activerecord concurrency

Hey,

I want to make sure that a user doesn't edit a row while another user is editing it.

A simple solution I figured was to set session[:editing] = row.id, and when a user clicks to edit a certain row, I'll just check the sessions for that row.id. If some user is already :editing row.id, then I'll render the necessary partial (e.g. "Cannot edit"). I have a problem with this approach, though, because the I use a link_to_remote "Edit",..., :id => row.id

Apparently, session.model.update_attribute(:editing, "row_id") doesn't work. When I include the update_attribute in a link_to :action, it works fine. Anyone have any suggestions?

action:

session.model.update_attribute(:editing, "row_id")     respond_to do |format|           format.html { redirect_to_index}           format.js         end

Also, are there any better ways to do this?

Thanks!!

Hey,

I want to make sure that a user doesn't edit a row while another user is editing it.

...

Also, are there any better ways to do this?

Is one way. -philip

There are two problems here that are completely distinct: - Two web requests are processed mostly simultaneously and you don't want the updates to walk all over each other. Optimistic locking is one way of dealing with this (I outlined some approaches here: Dealing with concurrency - Space Vatican) - Two users are editing something at the same time eg: user 1 loads up the edit form user 2 loads up the edit form user 1 saves user 2 saves, overwriting user 1's changes.

In the second case one way of dealing with it is having a field on the edited object that stores the id of the user edited it (and probably a timestamp so that you can deal with expired edit attempts).

Fred

> > > >> >> Hey, >> >> I want to make sure that a user doesn't edit a row while another >> user is >> editing it. >> > ... >> >> Also, are there any better ways to do this? > > http://api.rubyonrails.org/classes/ActiveRecord/Locking/ > Optimistic.html

There are two problems here that are completely distinct: - Two web requests are processed mostly simultaneously and you don't
want the updates to walk all over each other. Optimistic locking is
one way of dealing with this (I outlined some approaches here: Dealing with concurrency - Space Vatican) - Two users are editing something at the same time eg: user 1 loads up the edit form user 2 loads up the edit form user 1 saves user 2 saves, overwriting user 1's changes.

In the second case one way of dealing with it is having a field on the
edited object that stores the id of the user edited it (and probably a
timestamp so that you can deal with expired edit attempts).

I remember a thread on this a while back. As you point out the trick is what you do when you do have a conflict to minimise annoyance/disruption to the user. In the particular case of some of the stuff i've worked on there could be a good 5-10 minutes between starting to edit the form and you finishing it (and in general the work only needs doing once), in cases like that i've found the 'edit in progress' flag useful as it avoids two users expending essentially duplicate effort. In other cases that might be completely irrelevant.

Fred