Ruby on Rails

On Mar 29, 10:15 pm, Lille <lille.pengu...@gmail.com> wrote:
> Thanks gents.
>
> The nice thing about pessimistic locking for me could be that it would
> help avoid the user problem to which Walter refers and I wouldn't have
> to add columns to all my models, as I would for optimistic locking.
>
I think you are misusing terminology slightly - pessimistic locking
usually refers to database level locks (ie select ... for update)
which is definitely not appropriate for this sort of scenario.

> @Fred - I see you've written pretty often on the topic of optimistic
> locking. What, to your reckoning, are the minimum changes I'd need to
> make to my models & forms to ensure the following:
>
> + user 1 fails to make any updates to the resource they have obtained
> from find
> + user 2 arrives later, finds the object, and should have the ability
> to update the resource
>

Personally, unless you think you will be able to merge potentially
conflicting changes (as you would with git) the easiest think is to
mark records as locked by a user. You could build in lock expiry - if
it has been locked for over a certain duration, unlock the record
automatically

Fred
> Thanks,
>
> Lille
>
> On Mar 29, 12:40 pm, Walter Lee Davis <wa...@wdstudio.com> wrote:
>
>
>
> > On Mar 29, 2011, at 11:15 AM, Lille wrote:
>
> > > Hi,
>
> > > I'm hoping to make a parent and several of its dependent children
> > > available for updates by multiple users. I want to figure out how to
> > > implement and test the following:
>
> > > 1. A user 'checks out' a parent resource: when seeking to update,
> > > other users are informed that the resource and its dependent children
> > > are currently unavailable for updating.
>
> > > 2. A user 'checks out' a child resource: when seeking to update, other
> > > users are informed that the child is unavailable for updating, though
> > > the parent may be available.
>
> > In both of these cases, the only time that the user would "know" that  
> > the element was locked is when they request it initially, or after a  
> > failure to save due to a lock. Have a read of optimistic locking in  
> > the Rails Guide. The only issue I can think of here is one of user  
> > frustration. Let's say they had just spent 20 minutes writing an  
> > update to a record, now they can't save it, and won't ever be able to  
> > save it because the starting point for their edit has moved underneath  
> > them.
>
> > Walter
>
> > > I think a reason I'm stumped here is that I have little deployment
> > > experience. Yet, even so, how would I test the behaviors above,
> > > locally?
>
> > > Thanks for any comments,
>
> > > Lille
>
> > > --
> > > 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 athttp://groups.google.com/group/rubyonrails-talk?hl=en
> > > .

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