-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: allow lock!
to be extended
#84
Comments
@nikolai-b Not sure I understand, what's the difference to lock_info = client.lock(...)
raise Redlock::LockError unless lock_info ? |
No real difference, just often in rails bang methods do the same thing but > User.find_by(id: 1)
=> nil
> User.find_by!(id: 1)
=> ActiveRecord::RecordNotFound: Couldn't find User I understand that in ruby core the bang means it modifies the receiver. Yes I can do what you suggest if you prefer to keep the |
Hmm, the original implementation of this dates back before I stumbled into this gem :) I see what you mean now, and agree that the behaviour of So yes, if you think this is needed, please come up with a PR for it. Please be aware though lock() with a block given will unlock the resource when the block exits, so the implementation would need to look more like: def lock!(*args)
if block_given?
lock(*args).tap { |lock_info| raise ... unless lock_info }
else
lock(*args) do |lock_info|
raise ... unless lock_info
yield
end
end
end Not sure if it's really worth it.. |
I would like to extend a
lock!
Would you consider making
lock!
return thelock_info
and also allow it to be called without a block, e.g.The text was updated successfully, but these errors were encountered: