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 :)
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 :(
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]>:
> 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].
> 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.
>
>
--
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.
