class MyTask < ApplicationRecord
has_many :jobs, as: :ownerable, dependent: :destroy
accepts_nested_attributes_for :jobs, allow_destroy: true
before_save :set_some_data
end
class Job < ApplicationRecord
belongs_to :ownerable, polymorphic: true, optional: true
end
In the :set_some_data method, we actually take the values from all the jobs belonging to the MyTask object and perform some calculations and save the result in a column (actually, just a self.column_name = calculated_value, not actually calling save).
The problem is that the UPDATE on the column happens before any jobs marked for destruction ie with "_destroy" => 1 in the params. And so obviously, it includes data from the deleted jobs, which is incorrect.
I am currently doing the following - change callback to:
after_save :set_some_data
def set_some_data
#Do stuff
# WARNING: Don't use any method that will trigger an after_save callback. Infinite loop otherwise.
self.update_columns(column_name: calculated_value)
end
It does what I want. But is this a good solution? Can you suggest some better alternatives?
you can do this with with after_destroy and put the method in job.rb this will make sure when child deleted(job) it will call the parent to update the value
class Job < ApplicationRecord
belongs_to :ownerable, polymorphic: true, optional: true
after_destroy :update_parent
def update_parent
# check your parent model
self.ownerable.update_columns(column_name: calculated_value)
end
end
for more detail callback you can check this and
Related
I am having a model Evaluation that has many sub evaluations (self refential)
class Evaluation < ApplicationRecord
has_many :sub_evaluations, class_name: "Evaluation", foreign_key: "parent_id", dependent: :destroy
before_save :calculate_score
def calculate_score
# do something
end
end
I am creating and updating evaluation with sub evaluations as nested attributes.
calculate_score method is triggered on sub evaluation creation but not while updating. I have tried before_update and after_validation. But nothing seems to be working.
Evaluation form
= form_for #evaluation do |f|
...
= f.fields_for :sub_evaluations do |sub_evaluation|
...
What seems to be the issue?
This article helped me to fix the issue.
Child callback isn't triggered because the parent isn't "dirty".
The solution in the article is to "force" it to be dirty by calling attr_name_will_change! on a parent attribute that, in fact, does not change.
Here is the updated model code:
class Evaluation < ApplicationRecord
has_many :sub_evaluations, class_name: "Evaluation", foreign_key: "parent_id", dependent: :destroy
before_save :calculate_score
def calculate_score
# do something
end
def exam_id= val
exam_id_will_change!
#exam_id = val
end
end
See Active Model Dirty in the Rails API
There are models with has has_many through association:
class Event < ActiveRecord::Base
has_many :event_categories
has_many :categories, through: :event_categories
validates :categories, presence: true
end
class EventCategory < ActiveRecord::Base
belongs_to :event
belongs_to :category
validates_presence_of :event, :category
end
class Category < ActiveRecord::Base
has_many :event_categories
has_many :events, through: :event_categories
end
The issue is with assigning event.categories = [] - it immediately deletes rows from event_categories. Thus, previous associations are irreversibly destroyed and an event becomes invalid.
How to validate a presence of records in case of has_many, through:?
UPD: please carefully read sentence marked in bold before answering.
Rails 4.2.1
You have to create a custom validation, like so:
validate :has_categories
def has_categories
unless categories.size > 0
errors.add(:base, "There are no categories")
end
end
This shows you the general idea, you can adapt this to your needs.
UPDATE
This post has come up once more, and I found a way to fill in the blanks.
The validations can remain as above. All I have to add to that, is the case of direct assignment of an empty set of categories. So, how do I do that?
The idea is simple: override the setter method to not accept the empty array:
def categories=(value)
if value.empty?
puts "Categories cannot be blank"
else
super(value)
end
end
This will work for every assignment, except when assigning an empty set. Then, simply nothing will happen. No error will be recorded and no action will be performed.
If you want to also add an error message, you will have to improvise. Add an attribute to the class which will be populated when the bell rings.
So, to cut a long story short, this model worked for me:
class Event < ActiveRecord::Base
has_many :event_categories
has_many :categories, through: :event_categories
attr_accessor :categories_validator # The bell
validates :categories, presence: true
validate :check_for_categories_validator # Has the bell rung?
def categories=(value)
if value.empty?
self.categories_validator = true # Ring that bell!!!
else
super(value) # No bell, just do what you have to do
end
end
private
def check_for_categories_validator
self.errors.add(:categories, "can't be blank") if self.categories_validator == true
end
end
Having added this last validation, the instance will be invalid if you do:
event.categories = []
Although, no action will have been fulfilled (the update is skipped).
use validates_associated, official documentaion is Here
If you are using RSpec as your testing framework, take a look at Shoulda Matcher. Here is an example:
describe Event do
it { should have_many(:categories).through(:event_categories) }
end
I have a situation like this:
class Shop < ActiveRecord::Base
has_many :services, dependent: :destroy
end
class Service < ActiveRecord::Base
has_many :model_weeks, dependent: :destroy
end
class ModelWeek < ActiveRecord::Base
before_destroy :prevent_destroy, if: :default?
private
def prevent_destroy
false
end
end
When I try to destroy a shop, I get ActiveRecord::RecordNotDestroyed: Failed to destroy the record because it starts destroying the associated records first, and it gets prevented by the callback in the ModelWeek.
I could easily unset default for ModelWeek when destroying a shop, only if I could catch it. before_destroy in the Shop model does not get triggered prior to when the above mentioned exception is raised.
So, is there a way to catch this in Shop model, or if not, is it possible to "know" in the ModelWeek that destruction was triggered by a parent? I investigated parsing the caller, but it offers nothing useful, and it would be messy anyway...
i solved this problem by using a funny hack,
you just need to put the before_destroy line
before the association line
and it will run before_destroy before deleting the associations
Since rails has destruction chain from related children to parent, it really makes sense, right? To make it easy, we can overwrite the destroy method in ModelWeek like this:
class ModelWeek < ActiveRecord::Base
# before_destroy :prevent_destroy, if: :default?
def destroy
unless default?
super
end
end
end
After some research and testing, this is what I came up with:
This is the order in which the methods are being called (do_before_destroy are any methods specified in the before_destroy callback):
Shop.destroy
Service.destroy
ModelWeek.destroy
ModelWeek.do_before_destroy
Service.do_before_destroy
Shop.do_before_destroy
So, I can deal with anything preventing the destruction of a child (ModelWeek) in the destroy method of a parent (Shop):
# Shop
def destroy
# default is a scope
ModelWeek.default.where(service_id: self.services.pluck(:id)).each do |m|
m.unset_default
end
super
end
After that nothing prevents destruction of the child and the chain continues unprevented.
UPDATE
There is even better, cleaner solution, without a need for overriding the destroy of the parent and doing any queries:
class Shop < ActiveRecord::Base
has_many :services, dependent: :destroy, before_remove: :unset_default_week
private
def unset_default_week(service)
service.model_weeks.default.unset_default
end
end
The modern solution is to use a before_destroy callback in the parent model with prepend: true option, making the callback trigger before the destruction callback that's defined under the hood by dependent: :destroy on association.
class Service < ActiveRecord::Base
has_many :model_weeks, dependent: :destroy
before_destroy :handle_model_weeks, prepend: true
private
def handle_model_weeks
# special handling here
end
end
See also a Rails thread on this.
I have two associated classes like this:
class Purchase < ActiveRecord::Base
has_many :actions
before_create do |p|
self.actions.build
end
end
class Action < ActiveRecord::Base
belongs_to :purchase
before_save do |a|
false
end
end
The block in the Action class prevents it from saving. I was thinking doing Purchase.create will fail because it cannot save the child object. But while it does not save the Action, it commits the Purchase. How can i prevent the parent object to be saved when there is an error in the child object?
It turns out you have to rollback the transaction explicitly, errors from the child objects does not propagate. So i ended up with:
class Purchase < ActiveRecord::Base
has_many :actions
after_create do |p|
a = Action.new(purchase: p)
if !a.save
raise ActiveRecord::Rollback
end
end
end
class Action < ActiveRecord::Base
belongs_to :purchase
before_save do |a|
false
end
end
Take note that i also changed the before_create callback to after_create. Otherwise, since belongs_to also causes the parent to be saved, you will get a SystemStackError: stack level too deep.
I ran into this problem when dealing with race conditions where the child objects would pass a uniqueness validation, but then fail the database constraint (when trying to save the parent object), leading to childless (invalid) parent objects in the database.
A slightly more general solution to the one suggested by #lunr:
class Purchase < ActiveRecord::Base
has_many :actions
after_save do
actions.each do |action|
raise ActiveRecord::Rollback unless action.save
end
end
end
class Action < ActiveRecord::Base
belongs_to :purchase
before_save do |a|
false
end
end
Try to use this code in Purchase class:
validate :all_children_are_valid
def all_children_are_valid
self.actions.each do |action|
unless action.valid?
self.errors.add(:actions, "aren't valid")
break
end
end
end
Or use validates_associated in Purchase class:
validates_associated :actions
If in your business logic you can't save purchase without any action, then add a presence validator on actions inside purchases
validates :actions, length: {minimum: 1}, presence: true
I'm having trouble with Active Record callbacks in a model which contains accepts_nested_attributes
I call build_associated_partiesusing an after_create callback, but these values are not being saved and I get <nil> errors. I've also tried using before_create & after_initialize callbacks without success.
What is causing the callbacks to fail?
connection.rb
class Connection < ActiveRecord::Base
attr_accessible :reason, :established, :connector, :connectee1,
:connectee2, :connectee1_attributes,
:connectee2_attributes, :connector_attributes
belongs_to :connector, class_name: "User"
belongs_to :connectee1, class_name: "User"
belongs_to :connectee2, class_name: "User"
accepts_nested_attributes_for :connector, :connectee1, :connectee2
belongs_to :permission
after_create :build_associated_parties
# builds connectee's, connector, permission objects
def build_associated_parties
build_connector
build_connectee1
build_connectee2
build_permission
end
connection_controller.rb
class ConnectionsController < ApplicationController
def new
#connection = Connection.new
end
def create
#connection = Connection.new params[:connection]
if #connection.save
flash[:notice] = "Connection created successfully!"
redirect_to #connection
else
render :new
end
end
end
However, if I instead build these attributes inside the controller as shown below, I don't get the error. This is nice, but it seems to go against keeping business logic code out of the controller.
class ConnectionsController < ApplicationController
def new
#connection = Connection.new
#connection.build_connectee1
#connection.build_connectee2
#connection.build_connector
end
end
How can I accomplish the same functionality with code in the model? Are there advantages to keeping it in the model?
You called your method build_associated_parties after connection is created, so how these methods:
build_connector
build_connectee1
build_connectee2
build_permission
know what params it will use? So they don't know what values are passed into method then they will get error. In controller, they didn't have error because they used values of params[:connection].
On your form, if you already have fields for connector, connectee1, connectee2, you should put code which initialize object in your new controller. When you save #connection, it's saved those object too. I think these codes aren't need to put into model. Your model only should put other logic code, like search or calculation...
after_create is a big no. Use after_initialize in your model and use self inside your build_associated_parties method. See if that works.
Moved logic out of controller and back into model. However, the build_* code was overwriting the values I was passing into the nested attributes.
By adding unless {attribute} to these build_ methods, I was able to properly pass in the values.
class Connection < ActiveRecord::Base
attr_accessible :reason, :established, :connector, :connectee1, :connectee2,
:connectee1_attributes, :connectee2_attributes, :connector_attributes
belongs_to :connector, class_name: "User"
belongs_to :connectee1, class_name: "User"
belongs_to :connectee2, class_name: "User"
accepts_nested_attributes_for :connector, :connectee1, :connectee2
belongs_to :permission
after_initialize :build_associated_parties
validates :reason, :presence => true
validates_length_of :reason, :maximum => 160
#builds connectee's, connector, permission objects
def build_associated_parties
build_connector unless connector
build_connectee1 unless connectee1
build_connectee2 unless connectee2
end