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!!
--
Posted via http://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
On Aug 1, 2008, at 3:51 PM, Justin To wrote:> > 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 Is one way. -philip --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 2 Aug 2008, at 00:12, Philip Hallstrom wrote:> > > On Aug 1, 2008, at 3:51 PM, Justin To wrote: > >> >> 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.htmlThere 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: http://www.spacevatican.org/2008/6/8/dealing-with-concurrency) - 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 --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Sat, 2008-08-02 at 00:39 +0100, Frederick Cheung wrote:> > On 2 Aug 2008, at 00:12, Philip Hallstrom wrote: > > > > > > > On Aug 1, 2008, at 3:51 PM, Justin To wrote: > > > >> > >> 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: http://www.spacevatican.org/2008/6/8/dealing-with-concurrency) > - 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).---- #1 - your link has a closing paren which breaks the link...s/b http://www.spacevatican.org/2008/6/8/dealing-with-concurrency #2 - I have found opportunistic locking more than adequate (and safe from a lot of issues) but it took me a little while to figure out that I needed a hidden_field ''lock_version'' on my form to pass back to the controller for saving. And yes, it does require some coding effort in the controller to deal with a lock_version failure. Craig --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 2 Aug 2008, at 00:52, Craig White wrote:>> >> >> 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: http://www.spacevatican.org/2008/6/8/dealing-with-concurrency) >> - 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). > ---- > #1 - your link has a closing paren which breaks the link...s/b > http://www.spacevatican.org/2008/6/8/dealing-with-concurrency > > #2 - I have found opportunistic locking more than adequate (and safe > from a lot of issues) but it took me a little while to figure out > that I > needed a hidden_field ''lock_version'' on my form to pass back to the > controller for saving. And yes, it does require some coding effort in > the controller to deal with a lock_version failure.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 --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---