I have a model with a couple of accepts_nested_attributes_for. There is a requirement that I have at least one of each of the nested attributes when saving and moving on.
However, validation occurs pre-save, so when I'm removing an item and moving on, it let's it through.
How can I validate that when I've saved, I have at least one item of each nested type there?
There's a bug with accepts_nested_attributes_for. Meaning you have to be a little more devious when it comes to validations in the parent model.
You could use an :after_save callback in each of your nested models to check if it's the last one. But if there's many nested associations where you want to ensure at least one, this isn't very DRY.
This is however a valid workaround for the linked bug:
class Whatever < ActiveRecord::Base
:has_many => :association_a
:has_many => :association_b
def ensure_minimum_associations
bad_associations = [:association_a, :association_b].
select{|assoc| self.send(assoc).all?{|a| a.marked_for_destruction?}}
unless bad_associations.empty?
bad_associations.each do |association|
errors.add_to_base "Each #{self.class.name.downcase} must retain at least one #{association}"
end
return false
end
end
end
You can always call valid? on a model and it will run the validation.
I believe you're looking for validates_associated
Related
Im creating an object (recipe_change) that has many ingredient_changes. However I want to run my own validation of sort and prevent the creation of ingredient_changes if they dont pass. I started with a validation in the ingredient_changes but with that if I added an error the valid? would prevent the change from being submitted if one of the many ingredient_changes wasnt valid...which I dont want. So then I tried the following in my create method in the recipe_change controller and this almost did the job except once it deleted one it would break the loop and not do the rest:
#recipe_change.ingredient_changes.each do |change|
if ...long conditional statement...
#recipe_change.ingredient_changes.delete(change)
end
end
Is there a function like the array .reject! that works for associations like this. At this point in the code they are not saved to the database and Im trying to not save them to the database if they dont meet my condition.
You can use reject_if to filter out invalid ingredient_changes in recipe_change model like this:
class RecipeChange < ActiveRecord::Base
has_many :ingredient_changes, reject_if: :invalid_ingredient_change?
def invalid_ingredient_change?(attributes)
end
end
See: http://api.rubyonrails.org/classes/ActiveRecord/NestedAttributes/ClassMethods.html
I have a model:
class A < ActiveRecord::Base
has_many :B
end
And I want to reset or update A's B association, but only save it later:
a = A.find(...)
# a.bs == [B<...>, B<...>]
a.bs = []
#or
a.bs = [B.new, B.new]
# do some validation stuff on `a` and `a.bs`
So there might be some case where I will call a.save later or maybe not. In the case I don't call a.save I would like that a.bs stay to its original value, but as soon as I call a.bs = [], the old associations is destroyed and now A.find(...).bs == []. Is there any simple way to set a record association without persisting it in the database right away? I looked at Rails source and didn't find anything that could help me there.
Thanks!
Edit:
I should add that this is for an existing application and there are some architecture constraint that doesn't allow us to use the the regular ActiveRecord updating and validation tools. The way it works we have a set of Updater class that take params and assign the checkout object the value from params. There are then a set of Validater class that validate the checkout object for each given params. Fianlly, if everything is good, we save the model.
In this case, I'm looking to update the association in an Updater, validate them in the Validator and finally, persist it if everything check out.
In summary, this would look like:
def update
apply_updaters(object, params)
# do some stuff with the updated object
if(validate(object))
object.save(validate: false)
end
Since there are a lot of stuff going on between appy_updaters and object.save, Transaction are not really an option. This is why I'm really looking to update the association without persisting right away, just like we would do with any other attribute.
So far, the closest solution I've got to is rewriting the association cache (target). This look something like:
# In the updater
A.bs.target.clear
params[:bs].each{|b| A.bs.build(b)}
# A.bs now contains the parameters object without doing any update in the database
When come the time to save, we need to persist cache:
new_object = A.bs.target
A.bs(true).replace(new_object)
This work, but this feel kind of hack-ish and can easily break or have some undesired side-effect. An alternative I'm thinking about is to add a method A#new_bs= that cache the assigned object and A#bs that return the cached object if available.
Good question.
I can advice to use attributes assignment instead of collection manipulation. All validations will be performed as regular - after save or another 'persistent' method. You can write your own method (in model or in separated validator) which will validate collection.
You can delete and add elements to collection through attributes - deletion is performed by additional attribute _destroy which may be 'true' or 'false' (http://api.rubyonrails.org/classes/ActiveRecord/NestedAttributes/ClassMethods.html), addition - through setting up parent model to accept attributes.
As example set up model A:
class A < ActiveRecord::Base
has_many :b
accepts_nested_attributes_for :b, :allow_destroy => true
validates_associated :b # to validate each element
validate :b_is_correct # to validate whole collection
def b_is_correct
self.bs.each { |b| ... } # validate collection
end
end
In controller use plain attributes for model updating (e.g update!(a_aparams)). These methods will behave like flat attribute updating. And don't forget to permit attributes for nested collection.
class AController < ApplicationController
def update
#a = A.find(...)
#a.update(a_attributes) # triggers validation, if error occurs - no changes will be persisted and a.errors will be populated
end
def a_attributes
params.require(:a).permit([:attr_of_a, :b_attributes => [:attr_of_b, :_destroy]])
end
end
On form we used gem nested_form (https://github.com/ryanb/nested_form), I recommend it. But on server side this approach uses attribute _destroy as mentioned before.
I finally found out about the mark_for_destruction method. My final solution therefor look like:
a.bs.each(&:mark_for_destruction)
params[:bs].each{|b| a.bs.build(b)}
And then I can filter out the marked_for_destruction? entry in the following processing and validation.
Thanks #AlkH that made me look into how accepts_nested_attributes_for was working and handling delayed destruction of association.
How do I change an AcriveRecord from marked to be saved to make sure it does not get saved, from within the model itself?
Considering I can have a method run by a hook in activerecord, such as: before_save
for (hypothetical) example:
before_save :ignore_new_delete_exisiting_if_blank(self.attribute)
def ignore_new_delete_exisiting_if_blank(attribute)
self.do_not_save_me! if attribute.blank?
#what is that magic "do_not_save_me" method?
#Is there such thing, or something to achieve the same thing?
end
Update
My particular use case requires that no errors be thrown and other models to continue to be saved, even if this one will not. I should explain:
I am using model inheritance, and I am having an issue with figuring out how to let save the parent model, but if the child model instances are blank, (no values exist in certain attributes) they should not be persisted; however, the parent should still be persisted. This scenario does not let me make use of validations on the child model as that would block the parent from being persisted as well...
Your method should just return false to make it does not save.
Or you set the errors, which will allow to be more descriptive.
For example:
def ignore_new_delete_exisiting_if_blank_attribute
if attribute.blank?
errors.add(:base, "Not allowed to save if attribute is blank.")
end
end
Note that you cannot send parameters to a before_save. If you just want to make sure a record is not saved when an attribute is not present, you should use
validates_presence_of :attribute
[UPDATE]
When saving a parent model with children, you have to do something like accepts_nested_attributes_for, and in that call, you can specify which attributes must be given or when a child-record is ignored.
For example
accepts_nested_attributes_for :posts, :reject_if => proc { |attributes| attributes['title'].blank? }
will not save a post if the title is blank.
Hope this helps.
The "magic" is that when you return false from the method, the record won't be saved.
In your case:
def ignore_new_delete_exisiting_if_blank(attribute)
attribute.present?
end
I'm trying to do this
has_many :roles, :before_add => :enforce_unique
def enforce_unique(assoc)
false if exists? assoc
end
From the docs: "If a before_add callback throws an exception, the object does not get added to the collection". The using false above does not prevent the add, so I'm forced to do this:
def enforce_unique(assoc)
raise if exists? assoc
end
This way, it's true that it doesn't get added, but it also raises an exception that has to be handled. Not very useful to me here. I would prefer this to behave more like regular AR callback before_save, where returning FALSE also prevents the save (or add) but doesn't raise an exception.
In this case above, I would prefer this to just not add the assoc silently. Is there a way to do this? I missing something? Or is raising an exception the only option here?
The way to solve it I think is to use throw and catch, which in Ruby are meant for flow control. Raising an exception is not a good fit, since this isn't an exceptional circumstance.
I ended up doing:
catch(:duplicate) do
association.create({})
end
And then in the before_add callback, I did:
if(Class.where({}).first)
throw :duplicate
end
More on throw/catch here:
http://rubylearning.com/blog/2011/07/12/throw-catch-raise-rescue-im-so-confused/
If the association isn't polymorphic you can do something like:
validates_uniqueness_of :name_of_model
inside of Role where name_of_model us what you are associating with
this question is a bit old, but i came across the same problem recently. here is how i solved it:
def enforce_unique |obj, x|
v = obj.roles
if i = v.index(x)
v.slice! i
end
end
Since this question is about saving rather than preventing it being included in the list temporarily (eg by a controller that is not interested in controlling its models) you could try overriding save in the related model and just not save it if the role exists:
class Role < ActiveRecord::Base
belongs_to :user, inverse_of: :roles
def save
super unless self.new_record? && user.has_existing_role?(self)
end
end
Sidenote: I don't buy the skinny controller argument when used with the Active Record pattern as business logic has to be put somewhere. With a business domain poor pattern like Active Record (not referring to the Ruby AR gem specifically) it really needs to exist a layer above (ie in the controller layer), you may use service objects or the decorator pattern as a means to achieve this.
Another approach would be to override update methods like << for the association and silently drop the role if it matches an existing one. Details on overriding association methods are in the ActiveRecord Association Class Methods Documentation
Since has_one doesn't provide a before_add callback to allow validation,
how do I prevent rails from destroying the old association even when the
new one does'nt pass validation?
susan :has_one :shirt
shirt :belongs_to :susan
susan.shirt = a_nice_shirt
this destroys whatever association was present beforehand,
even if the new shirt is never realy associated because it didn't pass
validation, leaving a shirtless susan behind (well, acutally leaving a shirt
behind that doesn't belong to anyone..).
susan.build_shirt
does the same thing
Is there a good reason for the missing before_add callback that I overlooked?
I'm not sure why that callback isn't there, but you can always just add an Observer to the model, and verify the new association in a before_save. I'll assume "susan" is a User Model instance, and the shirt has to be red to pass validation.
class UserObserver< ActiveRecord::Observer
def before_save(user)
return false if user.shirt.color != "red"
end
end
If you return false in the observer, the object won't save. Of course, your current instance of "susan" will still have the invalid association. I'm not positive, but if you change the before_save_ in the observer to something like this:
class UserObserver< ActiveRecord::Observer
def before_save(user)
if user.shirt.color != "red"
user.reload
false
end
end
Might refresh the instance of your User. I've never tried this though.
In Rails validation is usually done when you try to save the object to the database (using save or save!), not when it's modified. If for any reason you would like to restore the old value when the validation fails you can either reload the object or use the new dirty attributes feature.
Look at this ticket:
http://dev.rubyonrails.org/ticket/10518
It appears that the functionality described there is still present if you have :dependent => :destroy on your association.
Personally, I think this is a bug in rails.