How to run validations of sub-class in Single Table Inheritance?

Question

In my application, I have a class called Budget. The budget can be of many types.. For instance, let's say that there are two budgets: FlatRateBudget and HourlyRateBudget. Both inherit from the class Budget.

This is what I get so far:

class Budget < ActiveRecord::Base
  validates_presence_of :price
end

class FlatRateBudget < Budget
end

class HourlyRateBudget < Budget
  validates_presence_of :quantity
end

In the console, if I do:

b = HourlyRateBudget.new(:price => 10)
b.valid?
=> false
b.errors.full_messages
=> ["Quantity can't be blank"]

As, expected.

The problem is that the "type" field, on STI, comes from params.. So i need to do something like:

b = Budget.new(:type => "HourlyRateBudget", :price => 10)
b.valid?
=> true

Which means that rails is running validations in the super-class instead of instantiating the sub class after I set up the type.

I know that is the expected behaviour, since I'm instantiating a class that dosen't need the quantity field, but I wonder if there is anyway to tell rails to run the validations for the subclass instead of the super.

Hypnogenesis

When using STI, I would avoid instantiating objects from the super class and only ever work with the base classes, which I believe Rails will then use the appropriate validations from the super class and those unique to the sub class. – Clever

Answer 1

You could probably solve this with a custom validator, similar to the answer on this question: Two models, one STI and a Validation However, if you can simply instantiate the intended sub-type to begin with, you would avoid the need for a custom validator altogether in this case.

As you've noticed, setting the type field alone doesn't magically change an instance from one type to another. While ActiveRecord will use the type field to instantiate the proper class upon reading the object from the database, doing it the other way around (instantiating the superclass, then changing the type field manually) doesn't have the effect of changing the object's type while your app is running - it just doesn't work that way.

The custom validation method, on the other hand, could check the type field independently, instantiate a copy of the appropriate type (based on the value of the type field), and then run .valid? on that object, resulting in the validations on the sub-class being run in a way that appears to be dynamic, even though it's actually creating an instance of the appropriate sub-class in the process.

Vancevancleave

Answer 2

I've done something similar.

Adapting it to your problem:

class Budget < ActiveRecord::Base

    validates_presence_of :price
    validates_presence_of :quantity, if: :hourly_rate?

    def hourly_rate?
        self.class.name == 'HourlyRateBudget'
    end

end

Pip

This isn't getting any upvotes... but it looks to me (as a rails noob) as a very railish solution. Does this work and is this still the way you would advise on solving this? – Laryngotomy

Great simple answer! You can use self.type == 'HourlyRateBudget' as well – Cloak

Answer 3

For anyone looking for example code, here's how I implemented the first answer:

validate :subclass_validations

def subclass_validations
  # Typecast into subclass to check those validations
  if self.class.descends_from_active_record?
    subclass = self.becomes(self.type.classify.constantize)
    self.errors.add(:base, "subclass validations are failing.") unless subclass.valid?
  end
end

Pollywog

It produce this error for me: NoMethodError (undefined method `type' for – Archespore

Does your model have a "type" field? – Pollywog

Answer 4

Instead of setting the type directly set the type like that... Instead, try:

new_type = params.fetch(:type)
class_type = case new_type
  when "HourlyRateBudget"
    HourlyRateBudget
  when "FlatRateBudget"
    FlatRateBudget
  else
    raise StandardError.new "unknown budget type: #{new_type}"
end
class_type.new(:price => 10)

You could even transform the string into its class by: new_type.classify.constantize but if it's coming in from params, that seems a bit dangerous.

If you do this, then you'll get a class of HourlyRateBudget, otherwise it'll just be Budget.

Sukey

That is a way to go, but I want to use accept_nested_attributes magic to keep my controller as thin as possible.. – Hypnogenesis

You can absolutely still do that. The trick is getting your string of type to a class. – Sukey

Answer 5

Better yet, use type.constantize.new("10"), however this depends on that the type from params must be correct string identical to HourlyRateBudget.class.to_s

Farkas

This answer is what I was going to recommend. However, you want to whitelist what is acceptable so someone doesn't pass in a malicious type. In a before_action you could do something like: render status: :forbidden unless type.constantize.in?([HourlyRateBudget, FlatRateBudget]) – Canon

Answer 6

I also required the same and with the help of Bryce answer i did this:

class  ActiveRecord::Base
  validate :subclass_validations, :if => Proc.new{ is_sti_supported_table? }

  def is_sti_supported_table?
  self.class.columns_hash.include? (self.class.inheritance_column)
  end

  def subclass_validations
      subclass = self.class.send(:compute_type, self.type)
      unless subclass == self.class
        subclass_obj= self.becomes(subclass)
        self.errors.add(:base, subclass_obj.errors.full_messages.join(', ')) unless subclass_obj.valid?
      end
  end
end

Mail

Answer 7

Along the lines of @franzlorenzon's answer, but using duck typing to avoid referencing class type in the super class:

class Budget < ActiveRecord::Base
  validates_presence_of :price
  validates_presence_of :quantity, if: :hourly_rate?

  def hourly_rate?
    false
  end
end

class HourlyRateBudget < Budget
  def hourly_rate?
    true
  end
end

Verminous