Currently, my model has these two relevant attributes: first_id, second_id
I'm trying to check that on update, if the first_id has changed, then set the second_id to nil, no matter what the value of second_id is.
So currently, my implementation in my model looks something like this:
validates_presence_of :first_id
before_action :check_if_first_id_changes, only: [:update]
def check_if_first_id_changes
if self.first_id != first_id
# What do I insert here?
end
end
Is there any way I can do this in the model? Thanks in advance!
before_action is a controller method. You probably want to use before_validation or before_save.
The following should work for your requirements:
before_validation :update_second_id_when_first_id_changed, on: [:update]
private
def update_second_id_when_first_id_changed
return unless first_id_changed?
self.second_id = nil
end
The check self.first_id != first_id is never going to work, because they both reference the same value. You can use the helper first_id_changed? to check if there was a change made. The ActiveModel::Dirty documentation provides a list of all helpers regarding model instance attribute changes.
Like already pointed out, before_action is not valid in a model. You can check the available callbacks for models here. If there are no validations for second_id I would personally go for before_update, which removes the need to set the on: :update option.
I personally like to split up the "action" and "check" so you are able to call the action without the check blocking it. I would then combine the two in a callback definition. This is however just personal preference and you could easily move the check into the callback if that suits your needs better.
before_update :clear_second_id, if: :first_id_changed?
private
def clear_second_id
self.second_id = nil
end
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 added #sort_by attribute to my controller, and initialized it's value like this:
class ProductsController < ApplicationController
def initialize
#sort_by = :shop_brand
end
...
end
This caused the default application layout not to be used.
Why ?
What is the right way to add an attribute to a controller and initialize it ?
Overriding the constructor is probably a bad idea (as you have found). You should use a before_filter:
class ProductsController < ApplicationController
before_filter :set_defaults
...
private
def set_defaults
#sort_by = :shop_brand
end
end
However, it sounds like you want to keep state. The easiest is to store in the user's session which will automatically persist per user until they close the browser:
def set_defaults
session[:sort_by] ||= :shop_brand
end
The other option would be to pass the current sort_by value in the URL. This is harder to implement though as you'll need to ensure each link or form copies the value over to the next request. The advantage of this however is the user could have multiple tabs open with different orderings and any bookmarked link would restore the same ordering next time. This is the approach that things like search engines would use.
In my controller i want to dynamically bind my instance method to the before_save callbacks.
Is there any ways we can dynamically bind methods to the callback from controller side....
EDIT :
Controller
This original code..
def amfupdate
set_properties
validate_record if params[:csv_header][:validate_record] == "Y" #On this condition...
super
end
If condition is true than i want to set custom callback that will exact call after before_save but before object is saved.
I want to call this method exact after before_save.. But if condition is true on controller side ..
In Model
def validate_record
self.csv_columns.each do |csv_column|
self.errors.add_to_base(_("Invalid column name #{csv_column.column_name}.")) \
unless self.model_name.constantize.column_names.include?(csv_column.column_name)
end
end
I think you're looking for something like the following. In the Model:
validate do |instance|
instance.csv_columns.each do |csv_column|
instance.errors.add :csv_columns, "Invalid column name #{csv_column.column_name}"
unless instance.class.column_names.include?(csv_column.column_name)
end
end
This will be called before the record is saved and will abort the save if the errors are added to
UPDATE: With suggestion for conditional validations
Add an attribute to the model
attr_accessor :some_condtional
Set this in the controller
#instance.some_conditional = true # or false
Then the validation now looks like this:
validate do |instance|
instance.csv_columns.each do |csv_column|
instance.errors.add :csv_columns, "Invalid column name #{csv_column.column_name}"
unless instance.class.column_names.include?(csv_column.column_name)
end if instance.some_conditional
end
Or something along those lines. In other words use the model to hold the state and communicate the logic
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)