On Tuesday, 26 February 2013 at 9:57 AM, Walther Diechmann wrote:
> If you will allow me my 2cents :)
>
> Record locking is one of the 'not invented here' features of most RDBMS's and
> hence Rails ;)
>
> We added an abstract class which all models inherits from (instead of
> ActiveRecord::Base) and implemented a few "core" methods on this class (and
> made sure all migrations of new models contains a 'locked_by int' field)
>
> def can_edit?(usr)
> # has usr permissions (with CanCan or else how)
>
> end
>
> def locked?(user_id)
> exec "update #{table_name} set locked_by=#{user_id} where id=#{id} and
> locked_by=0"
> end
>
> which allowed us to do this (in the controllers)
>
> def edit
> ..
> if can_edit?(current_user) && locked?(current_user)
> # render like any other day
> else
> # inject a flash with the error (either no edit permissions or not locked
> by current_user)
> end
> end
>
> def update
> ..
> params[:what_ever][:locked_by]=0
> if resource.update_attributes(params[:what_ever])
> ..
> end
>
> Currently, we are looking into the "collateral damage" (users starting to
> editing a record and then leaving for coffee, having a stroke or just plain
> drifts about in there, like it was Google search - leaving a bunch of locked
> records in their wake) - but hey, any solution is the offspring to a new
> challenge, right :)
>
What you've implemented is pessimistic locking, which is completely different
and comes with its own set of tradeoffs. If you expect conflicts to be rare,
you should use optimistic locking (you're 'optimistic' the lock isn't needed).
If you expect them to be common, you need to lock more actively.
>
> Originally we tried with optimistic locking and we did not like it at all -
> too many users saving data on top of each other - but then again that may
> just have been us implementing it the wrong way :(
>
>
This is exactly what optimistic locking is meant to prevent, users can't save
data over the top of each other if you're using optimistic locking correctly.
>
> Like I said - just my 2cents - and probably not what you wanted <:)
>
>
> cheers
> Walther
>
>
> ps. the above code is part pseudo-code - part copy/paste - you'd get the
> drift if it suits you, and ironing the 'small-print' out would not be a big
> feast :)
>
>
> Den 25/02/2013 kl. 18.28 skrev Brian McManus <[email protected]
> (mailto:[email protected])>:
> > I'm working on an app that makes use of rails' optimistic locking feature
> > and seeing some possibilities for improvements. It seems a bit tedious to
> > have to add :lock_version to forms wherever the model is used. You also
> > have to "hack" around rails' UJS feature to add it as a URL parameter when
> > using remote: true, method: [:put, :patch, :post, :delete]. On the
> > controller side in rails 4 (or if you're just using the strong_parameters
> > gem in 3.x) you have to remember to permit the :lock_version parameter
> > wherever you're using that model or it will just be silently ignored
> > rendering the protection useless.
> > It seems like this could all be handled in rails core by introspecting the
> > form object and injecting the lock_version as we do with the id and :method
> > currently. I'm having problems figuring out how to address it on the UJS
> > side. My current idea is to add a lock_with: option to link_to that works
> > similarly to :remote, :method, :confirm, etc. Also, I can't see any
> > obviously clean way to handle this magically wrt strong_parameters since
> > there is nothing inherent in strong_parameters that provides knowledge
> > about the model that may eventually be created/updated from said
> > parameters. Current plan there would be to create a module you can include
> > in ActionController::StrongParameters that would automatically append
> > :lock_version whenever permit is called. Not sure how to handle if you
> > change the lock column name in your model though...
> > Is this a viable approach for core or would this be better served as a gem
> > that just monkey patches everything it needs to if they are present in the
> > user's app?
> > Thanks in advance!
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Ruby on Rails: Core" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to [email protected]
> > (mailto:[email protected]).
> > To post to this group, send email to [email protected]
> > (mailto:[email protected]).
> > Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected]
> (mailto:[email protected]).
> To post to this group, send email to [email protected]
> (mailto:[email protected]).
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
