I have some models that have after_save callbacks. Usually that's fine, but in some situations, like when creating development data, I want to save the models without having the callbacks run. Is there a simple way to do that? Something akin to...
Person#save( :run_callbacks => false )
or
Person#save_without_callbacks
I looked in the Rails docs and didn't find anything. However in my experience the Rails docs don't always tell the whole story.
UPDATE
I found a blog post that explains how you can remove callbacks from a model like this:
Foo.after_save.clear
I couldn't find where that method is documented but it seems to work.
Use update_column (Rails >= v3.1) or update_columns (Rails >= 4.0) to skip callbacks and validations. Also with these methods, updated_at is not updated.
#Rails >= v3.1 only
#person.update_column(:some_attribute, 'value')
#Rails >= v4.0 only
#person.update_columns(attributes)
http://api.rubyonrails.org/classes/ActiveRecord/Persistence.html#method-i-update_column
#2: Skipping callbacks that also works while creating an object
class Person < ActiveRecord::Base
attr_accessor :skip_some_callbacks
before_validation :do_something
after_validation :do_something_else
skip_callback :validation, :before, :do_something, if: :skip_some_callbacks
skip_callback :validation, :after, :do_something_else, if: :skip_some_callbacks
end
person = Person.new(person_params)
person.skip_some_callbacks = true
person.save
UPDATE (2020)
Apparently Rails has always supported :if and :unless options, so above code can be simplified as:
class Person < ActiveRecord::Base
attr_accessor :skip_some_callbacks
before_validation :do_something, unless: :skip_some_callbacks
after_validation :do_something_else, unless: :skip_some_callbacks
end
person = Person.new(person_params)
person.skip_some_callbacks = true
person.save
This solution is Rails 2 only.
I just investigated this and I think I have a solution. There are two ActiveRecord private methods that you can use:
update_without_callbacks
create_without_callbacks
You're going to have to use send to call these methods. examples:
p = Person.new(:name => 'foo')
p.send(:create_without_callbacks)
p = Person.find(1)
p.send(:update_without_callbacks)
This is definitely something that you'll only really want to use in the console or while doing some random tests. Hope this helps!
Updated:
#Vikrant Chaudhary's solution seems better:
#Rails >= v3.1 only
#person.update_column(:some_attribute, 'value')
#Rails >= v4.0 only
#person.update_columns(attributes)
My original answer :
see this link: How to skip ActiveRecord callbacks?
in Rails3,
assume we have a class definition:
class User < ActiveRecord::Base
after_save :generate_nick_name
end
Approach1:
User.send(:create_without_callbacks)
User.send(:update_without_callbacks)
Approach2:
When you want to skip them in your rspec files or whatever, try this:
User.skip_callback(:save, :after, :generate_nick_name)
User.create!()
NOTE: once this is done, if you are not in rspec environment, you should reset the callbacks:
User.set_callback(:save, :after, :generate_nick_name)
works fine for me on rails 3.0.5
If the goal is to simply insert a record without callbacks or validations, and you would like to do it without resorting to additional gems, adding conditional checks, using RAW SQL, or futzing with your exiting code in any way, consider using a "shadow object" pointing to your existing db table. Like so:
class ImportedPerson < ActiveRecord::Base
self.table_name = 'people'
end
This works with every version of Rails, is threadsafe, and completely eliminates all validations and callbacks with no modifications to your existing code. You can just toss that class declaration in right before your actual import, and you should be good to go. Just remember to use your new class to insert the object, like:
ImportedPerson.new( person_attributes )
rails 3:
MyModel.send("_#{symbol}_callbacks") # list
MyModel.reset_callbacks symbol # reset
You could try something like this in your Person model:
after_save :something_cool, :unless => :skip_callbacks
def skip_callbacks
ENV[RAILS_ENV] == 'development' # or something more complicated
end
EDIT: after_save is not a symbol, but that's at least the 1,000th time I've tried to make it one.
You can use update_columns:
User.first.update_columns({:name => "sebastian", :age => 25})
Updates the given attributes of an object, without calling save, hence skipping validations and callbacks.
The only way to prevent all after_save callbacks is to have the first one return false.
Perhaps you could try something like (untested):
class MyModel < ActiveRecord::Base
attr_accessor :skip_after_save
def after_save
return false if #skip_after_save
... blah blah ...
end
end
...
m = MyModel.new # ... etc etc
m.skip_after_save = true
m.save
Looks like one way to handle this in Rails 2.3 (since update_without_callbacks is gone, etc.), would be to use update_all, which is one of the methods that skips callbacks as per section 12 of the Rails Guide to validations and callbacks.
Also, note that if you are doing something in your after_ callback, that does a calculation based on many association (i.e. a has_many assoc, where you also do accepts_nested_attributes_for), you will need to reload the association, in case as part of the save, one of its members was deleted.
The most up-voted answer might seem confusing in some cases.
You can use just a simple if check if you would like to skip a callback, like this:
after_save :set_title, if: -> { !new_record? && self.name_changed? }
with Rails 6 you can now use the insert methods
from the documentation:
Inserts multiple records into the database in a single SQL INSERT
statement. It does not instantiate any models nor does it trigger
Active Record callbacks or validations. Though passed values go
through Active Record's type casting and serialization.
https://gist.github.com/576546
just dump this monkey-patch into config/initializers/skip_callbacks.rb
then
Project.skip_callbacks { #project.save }
or the like.
all credit to the author
A solution that should work across all versions of Rails without the use of a gem or plugin is simply to issue update statements directly. eg
ActiveRecord::Base.connection.execute "update table set foo = bar where id = #{self.id}"
This may (or may not) be an option depending on how complex your update is. This works well for eg updating flags on a record from within an after_save callback (without retriggering the callback).
When I need full control over the callback, I create another attribute that is used as a switch. Simple and effective:
Model:
class MyModel < ActiveRecord::Base
before_save :do_stuff, unless: :skip_do_stuff_callback
attr_accessor :skip_do_stuff_callback
def do_stuff
puts 'do stuff callback'
end
end
Test:
m = MyModel.new()
# Fire callbacks
m.save
# Without firing callbacks
m.skip_do_stuff_callback = true
m.save
# Fire callbacks again
m.skip_do_stuff_callback = false
m.save
I needed a solution for Rails 4, so I came up with this:
app/models/concerns/save_without_callbacks.rb
module SaveWithoutCallbacks
def self.included(base)
base.const_set(:WithoutCallbacks,
Class.new(ActiveRecord::Base) do
self.table_name = base.table_name
end
)
end
def save_without_callbacks
new_record? ? create_without_callbacks : update_without_callbacks
end
def create_without_callbacks
plain_model = self.class.const_get(:WithoutCallbacks)
plain_record = plain_model.create(self.attributes)
self.id = plain_record.id
self.created_at = Time.zone.now
self.updated_at = Time.zone.now
#new_record = false
true
end
def update_without_callbacks
update_attributes = attributes.except(self.class.primary_key)
update_attributes['created_at'] = Time.zone.now
update_attributes['updated_at'] = Time.zone.now
update_columns update_attributes
end
end
in any model:
include SaveWithoutCallbacks
then you can:
record.save_without_callbacks
or
Model::WithoutCallbacks.create(attributes)
# for rails 3
if !ActiveRecord::Base.private_method_defined? :update_without_callbacks
def update_without_callbacks
attributes_with_values = arel_attributes_values(false, false, attribute_names)
return false if attributes_with_values.empty?
self.class.unscoped.where(self.class.arel_table[self.class.primary_key].eq(id)).arel.update(attributes_with_values)
end
end
None of these points to without_callbacks plugin that just does what you need ...
class MyModel < ActiveRecord::Base
before_save :do_something_before_save
def after_save
raise RuntimeError, "after_save called"
end
def do_something_before_save
raise RuntimeError, "do_something_before_save called"
end
end
o = MyModel.new
MyModel.without_callbacks(:before_save, :after_save) do
o.save # no exceptions raised
end
http://github.com/cjbottaro/without_callbacks works with Rails 2.x
I wrote a plugin that implements update_without_callbacks in Rails 3:
http://github.com/dball/skip_activerecord_callbacks
The right solution, I think, is to rewrite your models to avoid callbacks in the first place, but if that's impractical in the near term, this plugin may help.
If you are using Rails 2. You could use SQL query for updating your column without running callbacks and validations.
YourModel.connection.execute("UPDATE your_models SET your_models.column_name=#{value} WHERE your_models.id=#{ym.id}")
I think it should work in any rails versions.
For creating test data in Rails you use this hack:
record = Something.new(attrs)
ActiveRecord::Persistence.instance_method(:create_record).bind(record).call
https://coderwall.com/p/y3yp2q/edit
You can use sneaky-save gem: https://rubygems.org/gems/sneaky-save.
Note this cannot help in saving associations along without validations. It throws error 'created_at cannot be null' as it directly inserts the sql query unlike a model. To implement this, we need to update all auto generated columns of db.
For custom callbacks, use an attr_accessor and an unless in the callback.
Define your model as follows:
class Person << ActiveRecord::Base
attr_accessor :skip_after_save_callbacks
after_save :do_something, unless: :skip_after_save_callbacks
end
And then if you need to save the record without hitting the after_save callbacks you defined, set the skip_after_save_callbacks virtual attribute to true.
person.skip_after_save_callbacks #=> nil
person.save # By default, this *will* call `do_something` after saving.
person.skip_after_save_callbacks = true
person.save # This *will not* call `do_something` after saving.
person.skip_after_save_callbacks = nil # Always good to return this value back to its default so you don't accidentally skip callbacks.
Why would you want to be able to do this in development? Surely this will mean you are building your application with invalid data and as such it will behave strangely and not as you expect in production.
If you want to populate your dev db with data a better approach would be to build a rake task that used the faker gem to build valid data and import it into the db creating as many or few records as you desire, but if you are heel bent on it and have a good reason I guess that update_without_callbacks and create_without_callbacks will work fine, but when you are trying to bend rails to your will, ask yourself you have a good reason and if what you are doing is really a good idea.
One option is to have a separate model for such manipulations, using the same table:
class NoCallbacksModel < ActiveRecord::Base
set_table_name 'table_name_of_model_that_has_callbacks'
include CommonModelMethods # if there are
:
:
end
(Same approach might make things easier for bypassing validations)
Stephan
Another way would be to use validation hooks instead of callbacks. For example:
class Person < ActiveRecord::Base
validate_on_create :do_something
def do_something
"something clever goes here"
end
end
That way you can get the do_something by default, but you can easily override it with:
#person = Person.new
#person.save(false)
Something that should work with all versions of ActiveRecord without depending on options or activerecord methods that may or may not exist.
module PlainModel
def self.included(base)
plainclass = Class.new(ActiveRecord::Base) do
self.table_name = base.table_name
end
base.const_set(:Plain, plainclass)
end
end
# usage
class User < ActiveRecord::Base
include PlainModel
validates_presence_of :email
end
User.create(email: "") # fail due to validation
User::Plain.create(email: "") # success. no validation, no callbacks
user = User::Plain.find(1)
user.email = ""
user.save
TLDR: use a "different activerecord model" over the same table
I faced the same problem when I wanted to run a Rake Task but without running the callbacks for every record I was saving.
This worked for me (Rails 5), and it must work for almost every version of Rails:
class MyModel < ApplicationRecord
attr_accessor :skip_callbacks
before_create :callback1
before_update :callback2
before_destroy :callback3
private
def callback1
return true if #skip_callbacks
puts "Runs callback1"
# Your code
end
def callback2
return true if #skip_callbacks
puts "Runs callback2"
# Your code
end
# Same for callback3 and so on....
end
The way it works is that it just returns true in the first line of the method it skip_callbacks is true, so it doesn't run the rest of the code in the method.
To skip callbacks you just need to set skip_callbacks to true before saving, creating, destroying:
rec = MyModel.new() # Or Mymodel.find()
rec.skip_callbacks = true
rec.save
Not the cleanest way, but you could wrap the callback code in a condition that checks the Rails environment.
if Rails.env == 'production'
...
Related
I'm setting up an after_save callback in my model observer to send a notification only if the model's published attribute was changed from false to true. Since methods such as changed? are only useful before the model is saved, the way I'm currently (and unsuccessfully) trying to do so is as follows:
def before_save(blog)
#og_published = blog.published?
end
def after_save(blog)
if #og_published == false and blog.published? == true
Notification.send(...)
end
end
Does anyone have any suggestions as to the best way to handle this, preferably using model observer callbacks (so as not to pollute my controller code)?
Rails 5.1+
Use saved_change_to_published?:
class SomeModel < ActiveRecord::Base
after_update :send_notification_after_change
def send_notification_after_change
Notification.send(…) if (saved_change_to_published? && self.published == true)
end
end
Or if you prefer, saved_change_to_attribute?(:published).
Rails 3–5.1
Warning
This approach works through Rails 5.1 (but is deprecated in 5.1 and has breaking changes in 5.2). You can read about the change in this pull request.
In your after_update filter on the model you can use _changed? accessor. So for example:
class SomeModel < ActiveRecord::Base
after_update :send_notification_after_change
def send_notification_after_change
Notification.send(...) if (self.published_changed? && self.published == true)
end
end
It just works.
For those who want to know the changes just made in an after_save callback:
Rails 5.1 and greater
model.saved_changes
Rails < 5.1
model.previous_changes
Also see: http://api.rubyonrails.org/classes/ActiveModel/Dirty.html#method-i-previous_changes
To anyone seeing this later on, as it currently (Aug. 2017) tops google: It is worth mentioning, that this behavior will be altered in Rails 5.2, and has deprecation warnings as of Rails 5.1, as ActiveModel::Dirty changed a bit.
What do I change?
If you're using attribute_changed? method in the after_*-callbacks, you'll see a warning like:
DEPRECATION WARNING: The behavior of attribute_changed? inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after save returned (e.g. the opposite of what it returns now). To maintain the current behavior, use saved_change_to_attribute? instead. (called from some_callback at /PATH_TO/app/models/user.rb:15)
As it mentions, you could fix this easily by replacing the function with saved_change_to_attribute?. So for example, name_changed? becomes saved_change_to_name?.
Likewise, if you're using the attribute_change to get the before-after values, this changes as well and throws the following:
DEPRECATION WARNING: The behavior of attribute_change inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after save returned (e.g. the opposite of what it returns now). To maintain the current behavior, use saved_change_to_attribute instead. (called from some_callback at /PATH_TO/app/models/user.rb:20)
Again, as it mentions, the method changes name to saved_change_to_attribute which returns ["old", "new"].
or use saved_changes, which returns all the changes, and these can be accessed as saved_changes['attribute'].
In case you can do this on before_save instead of after_save, you'll be able to use this:
self.changed
it returns an array of all changed columns in this record.
you can also use:
self.changes
which returns a hash of columns that changed and before and after results as arrays
The "selected" answer didn't work for me. I'm using rails 3.1 with CouchRest::Model (based on Active Model). The _changed? methods don't return true for changed attributes in the after_update hook, only in the before_update hook. I was able to get it to work using the (new?) around_update hook:
class SomeModel < ActiveRecord::Base
around_update :send_notification_after_change
def send_notification_after_change
should_send_it = self.published_changed? && self.published == true
yield
Notification.send(...) if should_send_it
end
end
you can add a condition to the after_update like so:
class SomeModel < ActiveRecord::Base
after_update :send_notification, if: :published_changed?
...
end
there's no need to add a condition within the send_notification method itself.
You just add an accessor who define what you change
class Post < AR::Base
attr_reader :what_changed
before_filter :what_changed?
def what_changed?
#what_changed = changes || []
end
after_filter :action_on_changes
def action_on_changes
#what_changed.each do |change|
p change
end
end
end
I have an auction and a bid object in my application, when someone presses the BID BUTTON it then calls the BID CREATE controller which created the bid, and then does some other things on the auction object:
BIDS CONTROLLER -> CREATE
#auction.endtime += #auction.auctiontimer
#auction.winner = #auction.arewinning
#auction.save
AUCTION MODEL
before_update :set_endtime
def set_endtime
self.endtime=self.starttime+self.auctiontimer
end
So the question is: How can C skip the "before callback" only, in this specific #auction.save
skip_callback is a complicated and not granular option.
I prefer to use an attr_accessor:
attr_accessor :skip_my_method, :skip_my_method_2
after_save{ my_method unless skip_my_method }
after_save{ my_method_2 unless skip_my_method_2 }
That way you can be declarative when skipping a callback:
model.create skip_my_method: true # skips my_method
model.create skip_my_method_2: true # skips my_method_2
ActiveSupport::Callbacks::ClassMethods#skip_callback is not threadsafe, it will remove callback-methods for time till it is being executed and hence and another thread at same time cannot get the callback-methods for execution.
Look at the informative post by Allerin - SAVE AN OBJECT SKIPPING CALLBACKS IN RAILS APPLICATION
You can try skipping callback with skip_callback
http://www.rubydoc.info/docs/rails/4.0.0/ActiveSupport/Callbacks/ClassMethods:skip_callback
You can use update_columns
See this http://edgeguides.rubyonrails.org/active_record_callbacks.html#skipping-callbacks
Is there any specific condition like when you don't have endtime then only you need to set end time if that the you can do
def set_endtime
if endtime.nil?
self.endtime=self.starttime+self.auctiontimer
end
end
OR
before_update :set_endtime if: Proc.new { |obj| obj.endtime.nil? }
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.
Right now I cant find a way to generate a callback between lines 1 and 2 here:
f = Foo.new
f.some_call
f.save!
Is there any way to simulate what would be effectively an after_new callback? Right now I'm using after_initialize but there are potential performance problems with using that since it fires for a lot of different events.
You can use the after_initialize callback
# app/models/foo.rb
class Foo < ActiveRecord::Base
after_initialize :some_call
def some_call
puts "Who you gonna call?"
end
end
# rails console
> foo = Foo.new # => "Who you gonna call?"
> foo = Foo.first # => "Who you gonna call?"
Beware after_initialize is triggered every time ActiveRecord do a Foo.new (calls like new, find, first and so on) see the Rails Guide
So you probably want something like this after_initialize :some_call, :if => :new_record?
# app/models/foo.rb
class Foo < ActiveRecord::Base
after_initialize :some_call, :if => :new_record?
def some_call
puts "Who you gonna call?"
end
end
# rails console
> foo = Foo.new # => "Who you gonna call?"
> foo = Foo.first
Define a constructor for Foo and do what you need to do there.
An alternate solution would be to look into using after_initialize but that may not do quite what you expect.
If this is a Active Record model, then after_initialize is the correct way to handle callbacks after object creation. The framework itself makes certain assumptions about the way objects will be created from the database. Performance should not be a concern unless you have some long-running task being triggered in the callback, in which case you probably need to rethink the strategy.
If not an AR model, you can create an initialize method in your object and place the code there.
There are a number of other callbacks available depending on want you want to do, including after_create (called when a new record is created).
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)