Yes, to be clear I'm only talking about optimistic locking here.
On Monday, February 25, 2013 1:05:11 PM UTC-8, Michael Koziarski wrote:
>
>
> 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]<javascript:>
> >:
>
> 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] <javascript:>.
> To post to this group, send email to [email protected]<javascript:>
> .
> 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] <javascript:>.
> To post to this group, send email to [email protected]<javascript:>
> .
> 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.
