I'm trying to run all callback methods manually inside a method. For example, I want to run all "before_destroy" methods inside my model.
Is there a way to manually trigger this? For example, something like:
def some_method
# ...
trigger(:before_destroy)
end
which will then run all methods that I have declared with "before_destroy :...."
Any ideas?
If you're happy to run both :before and :after hooks, you can try run_callbacks.
From the docs:
run_callbacks(kind, &block)
Runs the callbacks for the given event.
Calls the before and around callbacks in the order they were set, yields the block (if given one), and then runs the after callbacks in reverse order.
If the callback chain was halted, returns false. Otherwise returns the result of the block, or true if no block is given.
run_callbacks :save do
save
end
class Foo < ActiveRecord::Base
def destroy_method_1
end
def destroy_method_2
end
before_destroy :destroy_method_1, :destroy_method_2
DESTROY_METHODS = [:destroy_method_1, :destroy_method_2]
def some_method
DESTROY_METHODS.each {|m| send(m) }
end
end
Related
Lets say I have a method in my model
class Mod < ...
after_create :update_some_stuff
private
def update_some_stuff
....
end
end
And I want to ensure that "update some stuff" is only called by after create, and to raise an error if it is called in any other context. Is there a way to do this in Ruby on Rails?
maybe you can use a block and avoid doing weird tricks to prevent the method getting called outside the context you want:
after_create do
....
end
It's hacky, and you probably don't need to be testing this because Rails tests this for you, but this should work:
class Mod < ...
after_create :update_some_stuff
private
def update_some_stuff
return unless id_previously_changed?
# do something
end
end
This hooks into previous_changes which is implemented by ActiveModel::Dirty.
In a Rails app, I'm using an after_update call back that runs multiple methods upon passing a conditional method such as below:
app/models/my_model.rb
class MyModel < ApplicationRecord
after_update :method_1, :method_2, :method_3, if: :this_happens?
#some custom methods
private
def this_happens?
# a condition that returns true or false here
end
end
I've noticed that the method this_happens? is executed three times, just before :method_1, :method_2, :method_3.
This make sense as any of those three call back methods could change the data in such a way that the condition has to be evaluated again to make sure it's met in every case. However, when you know those 3 methods are not changing the data in any way that could alter the condition evaluation, is it possible to run this_happens? only once and gain some efficiency?
I don't seem to find anything online and wonder if anyone could advise.
PS. using Rails 5.1
Encapsulation is the one of the easiest way that you can choose to overcome this situation.
Just wrap your methods in another one, then it will only check this_happens? one time.
class MyModel < ApplicationRecord
after_update :combine_methods, if: :this_happens?
#some custom methods
private
def combine_methods
method_1
method_2
method_3
end
def this_happens?
# a condition that returns true or false here
end
end
Is there a way to hook into the save! with a callback?
I am looking for something like:
class CompositeService < Service
attr_accessible :subservices
before_save :save_subservices
before_save :save_subservices! if bang_save?
private
def save_subservices
#subservices.each(&:save)
end
def save_subservices!
#subservices.each(&:save!)
end
end
Where a save! is cascaded and calls save! on the (faux) association subservices.
Technically you can do this, but I would advise not to use this approach in production because it can change in newer rails. And it is just wrong.
You can inspect call stack of your before callback and check if there is save! method.
class CompositeService < Service
before_save :some_callback
def some_callback
lines = caller.select { |line| line =~ /persistence.rb/ && line =~ /save!/ }
if lines.any?
#subservices.each(&:save!)
else
#subservices.each(&:save)
end
end
end
I wonder: is this extra logic even necessary?
If the save method on each of your #subservices obeys the ActiveRecord save semantics, then you probably will get the correct behavior for free.
In other words, make sure your save methods return true or false for success or failure. Then, the composite code becomes as simple as this:
class CompositeService < Service
attr_accessible :subservices
before_save :save_subservices
private
def save_subservices
#subservices.all?(&:save)
end
end
If any of your sub services fail to save, then the save_subservices callback will return false, which will abort the callback chain. This will cause the wrapping save to return false. And in the case of save!, it will raise an exception.
composite.save
# => false
composite.save!
# => ActiveRecord::RecordNotSaved
Look at ActiveRecord autosave attribute:
http://api.rubyonrails.org/classes/ActiveRecord/AutosaveAssociation.html
I have an observer and I register an after_commit callback.
How can I tell whether it was fired after create or update?
I can tell an item was destroyed by asking item.destroyed? but #new_record? doesn't work since the item was saved.
I was going to solve it by adding after_create/after_update and do something like #action = :create inside and check the #action at after_commit, but it seems that the observer instance is a singleton and I might just override a value before it gets to the after_commit. So I solved it in an uglier way, storing the action in a map based on the item.id on after_create/update and checking its value on after_commit. Really ugly.
Is there any other way?
Update
As #tardate said, transaction_include_action? is a good indication, though it's a private method, and in an observer it should be accessed with #send.
class ProductScoreObserver < ActiveRecord::Observer
observe :product
def after_commit(product)
if product.send(:transaction_include_action?, :destroy)
...
Unfortunately, the :on option does not work in observers.
Just make sure you test the hell of your observers (look for test_after_commit gem if you use use_transactional_fixtures) so when you upgrade to new Rails version you'll know if it still works.
(Tested on 3.2.9)
Update 2
Instead of Observers I now use ActiveSupport::Concern and after_commit :blah, on: :create works there.
I think transaction_include_action? is what you are after. It gives a reliable indication of the specific transaction in process (verified in 3.0.8).
Formally, it determines if a transaction included an action for :create, :update, or :destroy. Used in filtering callbacks.
class Item < ActiveRecord::Base
after_commit lambda {
Rails.logger.info "transaction_include_action?(:create): #{transaction_include_action?(:create)}"
Rails.logger.info "transaction_include_action?(:destroy): #{transaction_include_action?(:destroy)}"
Rails.logger.info "transaction_include_action?(:update): #{transaction_include_action?(:update)}"
}
end
Also of interest may be transaction_record_state which can be used to determine if a record was created or destroyed in a transaction. State should be one of :new_record or :destroyed.
Update for Rails 4
For those seeking to solve the problem in Rails 4, this method is now deprecated, you should use transaction_include_any_action? which accepts an array of actions.
Usage Example:
transaction_include_any_action?([:create])
I've learned today that you can do something like this:
after_commit :do_something, :on => :create
after_commit :do_something, :on => :update
Where do_something is the callback method you want to call on certain actions.
If you want to call the same callback for update and create, but not destroy, you can also use:
after_commit :do_something, :if => :persisted?
It's really not documented well and I had a hard time Googling it. Luckily, I know a few brilliant people. Hope it helps!
You can solve by using two techniques.
The approach suggested by #nathanvda i.e. checking the created_at and updated_at. If they are same, the record is newly created, else its an update.
By using virtual attributes in the model. Steps are:
Add a field in the model with the code attr_accessor newly_created
Update the same in the before_create and before_update callbacks as
def before_create (record)
record.newly_created = true
end
def before_update (record)
record.newly_created = false
end
Based on leenasn idea, I created some modules that makes it possible to use after_commit_on_updateand after_commit_on_create callbacks: https://gist.github.com/2392664
Usage:
class User < ActiveRecord::Base
include AfterCommitCallbacks
after_commit_on_create :foo
def foo
puts "foo"
end
end
class UserObserver < ActiveRecord::Observer
def after_commit_on_create(user)
puts "foo"
end
end
Take a look at the test code: https://github.com/rails/rails/blob/master/activerecord/test/cases/transaction_callbacks_test.rb
There you can find:
after_commit(:on => :create)
after_commit(:on => :update)
after_commit(:on => :destroy)
and
after_rollback(:on => :create)
after_rollback(:on => :update)
after_rollback(:on => :destroy)
I use the following code to determine whether it is a new record or not:
previous_changes[:id] && previous_changes[:id][0].nil?
It based on idea that a new record has default id equal to nil and then changes it on save.
Of course id changing is not a common case, so in most cases the second condition can be omitted.
I'm curious to know why you couldn't move your after_commit logic into after_create and after_update. Is there some important state change that happens between the latter 2 calls and after_commit?
If your create and update handling has some overlapping logic, you could just have the latter 2 methods call a third method, passing in the action:
# Tip: on ruby 1.9 you can use __callee__ to get the current method name, so you don't have to hardcode :create and :update.
class WidgetObserver < ActiveRecord::Observer
def after_create(rec)
# create-specific logic here...
handler(rec, :create)
# create-specific logic here...
end
def after_update(rec)
# update-specific logic here...
handler(rec, :update)
# update-specific logic here...
end
private
def handler(rec, action)
# overlapping logic
end
end
If you still rather use after_commit, you can use thread variables. This won't leak memory as long as dead threads are allowed to be garbage-collected.
class WidgetObserver < ActiveRecord::Observer
def after_create(rec)
warn "observer: after_create"
Thread.current[:widget_observer_action] = :create
end
def after_update(rec)
warn "observer: after_update"
Thread.current[:widget_observer_action] = :update
end
# this is needed because after_commit also runs for destroy's.
def after_destroy(rec)
warn "observer: after_destroy"
Thread.current[:widget_observer_action] = :destroy
end
def after_commit(rec)
action = Thread.current[:widget_observer_action]
warn "observer: after_commit: #{action}"
ensure
Thread.current[:widget_observer_action] = nil
end
# isn't strictly necessary, but it's good practice to keep the variable in a proper state.
def after_rollback(rec)
Thread.current[:widget_observer_action] = nil
end
end
This is similar to your 1st approach but it only uses one method (before_save or before_validate to really be safe) and I don't see why this would override any value
class ItemObserver
def before_validation(item) # or before_save
#new_record = item.new_record?
end
def after_commit(item)
#new_record ? do_this : do_that
end
end
Update
This solution doesn't work because as stated by #eleano, ItemObserver is a Singleton, it has only one instance. So if 2 Item are saved at the same time #new_record could take its value from item_1 while after_commit is triggered by item_2. To overcome this problem there should be an item.id checking/mapping to "post-synchornize" the 2 callback methods : hackish.
You can change your event hook from after_commit to after_save, to capture all create and update events. You can then use:
id_changed?
...helper in the observer. This will be true on create and false on an update.
I have a model that uses after_update to log changes. There is a case where I would like to make a change to the model without activating this logging mechanism. Is there a way to pass in a parameter to after_update, or skip it all together?
I would like a nice solution to this, and am willing to remove after_update if there is a better way to go about it.
I would go with the approach of adding a boolean to the model as suggested but would then write a method to help set and clear the flag after your update. e.g.
def without_logging_changes_to(model)
# store current value of the flag so it can be restored
# when we leave the block
remembered_value = model.log_update
model.log_update = false
begin
yield
ensure
model.log_update = remembered_value
end
end
Then to use it:
without_logging_changes_to my_model do
my_model.update_attributes(updates)
end
You could add a boolean to your model that is something like log_last_update and check that in the after_update callback.
class MyModel < ActiveRecord::Base
after_update :do_something
attr_accessor :should_do_something
def should_do_something?
should_do_something != false
end
def do_something
if should_do_something?
...
end
end
end
y = MyModel.new
y.save! # callback is triggered
n = MyModel.new
n.should_do_something = false
n.save! # callback isn't triggered
In Rails 2 you can use private ActiveRecord methods
update_without_callbacks
create_without_callbacks
They can be invoked via the send method:
# Update attributes on your model
your_model.some_attribute = some_value
# Update model without callbacks
your_model.send(:update_without_callbacks)