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
Allow after_commit :do_something, :on => [:update, :create] #988
Comments
Imported from Lighthouse. I just encountered this same bug today and was fortunate to find this bug report from a day ago. I have the same situation and I'd like to run the same actions but only on create/update, not destroy. I definitely wouldn't expect that using after_commit twice would override the first action. |
Imported from Lighthouse. Also, I believe you can work around this exact issue by defining a single callback and only running it if the object is persisted: after_commit :do_something, :if => :persisted? |
Imported from Lighthouse. Yes, thanks! That worked. So what do we do about this? Close as invalid? Still propose to do it? (I will try to make a patch for this) |
Imported from Lighthouse. I still thing it's a valid bug, the behavior is certainly not as I'd expect. Callbacks are never supposed to override each other like this. At a glance it didn't look like the patch would be very simple, but go ahead and take a crack at it. Hopefully we can get some assistance from the core team. |
Imported from Lighthouse. I also recently encountered this problem. Here is a unit test demonstrating this behavior: |
Imported from Lighthouse. Updated the pull request with a fix to prevent the callbacks in separate contexts from overriding one another. |
Was this ever fixed?
Stacking them also doesn't work, as mentioned before:
In the official documentation they suggest Re-open as a bug? |
@naoisegolden done |
I was trying to send a notification after both creation and deletion when I saw this issue. That would be great if this peace of code could work : The |
This is only for Rails 4, right? Any Rails 3.2.x work around? |
@Frexuz the workaround i've used is to do the following after_commit :do_something_on_create, on: :create
after_commit :do_something_on_destory, on: :destroy
alias :do_something_on_create :do_something
alias :do_something_on_destroy :do_something or alternatively after_commit ->(obj) { obj.do_something }, on: :create
after_commit ->(obj) { obj.do_something }, on: :update |
👍 to @seako workaround!! |
Hi! I just came through this bug again in the My code looks like exactly the same as mentioned before: after_commit :my_method, on: :create # not fired
after_commit :my_method, on: :update # fired So here, Does somebody else have the same bug with this branch? Thanks :) |
It is not a bug. You are defining the same callback just with different arguments, so only the last one will be fired. |
Hi @rafaelfranca ! |
As only one `after_commit` callback is executed. See: rails/rails#988 (comment) https://trello.com/c/6dNTE3FL/1-renew-cache
Imported from Lighthouse. Original ticket at: http://rails.lighthouseapp.com/projects/8994/tickets/6660
Created by Ary Borenszweig - 2011-03-31 17:48:22 UTC
It's very common to want to do the same thing on an update/create callback after commit (example: create/update a related file, but if the file was there then it is just overwritten).
I tried:
but I get:
I tried doing this:
but the second callback overrides the first one. So for now I'm using two different methods, or just using an alias_method, but I think the :on => [...] is more DRY, useful and it also similar to the controllers :before_filter, :only => [...]
The text was updated successfully, but these errors were encountered: