Rails validations and initializations with interdependent fields - ruby-on-rails

Question

After coding in Rails for a couple of years, I still don't understand the Rails Way for more advanced concepts. The Rails Way is so specific about convention over configuration, however when you get into Enterprise coding, all rules go out the window and everyone writes blogs with non-standard way of doing things. Here's another one of those situations: contextual validations where the context is a little more complex (fields depend on each other). Basically in a shipping application, I need to initialize an AR object with request params and with some calculated values. The calculated values are dependent on the request params, and I'm not sure how to initialize and validate my member variables.
table mailpieces
mail_class
weight
sort_code
t_indicator_id
end
class Mailpiece
validates_presence_of: :mail_class
validates_presence_of: :weight
validates_presence_of: :sort_code
validates_presence_of: :t_indicator_id
def some_kind_of_initializer
if mail_class == 'Priority'
sort_code = '123'
elsif mail_class == 'Express'
if weight < 1
sort_code = '456'
else
sort_code = '789'
end
end
t_indicator = ndicator.find_by(name: 'blah')
if sort_code = '456'
t_indicator = Indicator.find_by(name: 'foobar')
end
end
end
mailpiece = Mailpiece.new(
mail_class: params[:mail_class],
weight: params[:weight])
#mailpiece.some_kind_of_initializer ?!
raise 'SomeError' if !mailpiece.valid?
What should some_kind_of_initializer be?
Override of ActiveRecord initialize? That's not good practice.
after_initialize. More Rails Way-sy.
Custom method called after
Mailpiece.new (e.g. mailpiece.some_kind_of_initializer)
Whichever of the above choices, the problem is that the initialization of sort_code and t_indicator depends on mail_class and weight being valid. Given that mail_class and weight should be not null before I enter some_kind_of_initializer, how should I write my validations?
Extract all validations into a json schema validation. More complex business rules around mail_class and weight are difficult to write in a json schema.
Extract all validations into some type of Data Transfer Object validation class. Moves away from the Rails Way of doing things. Feels like I'm writing in .NET/Java and I'm afraid that Rails will kick my azz later (in validations, testing, etc.).
Assign sort_code only if mail_class and weight have been initialized. This seems to be most Rails Way to write things, but it's tough. So many if/else. This is just a simple example, but my mailpiece has references that have references and they all do these type of validations. If this is the right answer, then I'm getting a gut feeling that it might be easier to move ALL validations and ALL initializations to an external class/module - perhaps getting close to option #2.
Option 3 code rewrite
def some_kind_of_initializer
if mail_class && weight
if (mail_class == 'Priority')
sort_code = '123'
elsif (mail_class == 'Express')
if weight < 1
sort_code = '456'
else
sort_code = '789'
end
end
end
if sort_code
t_indicator = Indicator.find_by(name: 'blah')
if sort_code = '456'
t_indicator = Indicator.find_by(name: 'foobar')
end
end
end
I'd love to hear your opinion on this. It seems to me this is such a popular use case of AR and I'm not sure what to do. Again, this is a just a simple case. My Mailpiece model has many other references that have dependencies on the mailpiece object properties and their own interdependencies in the same style as above.

Answer 1

I'm not sure if it helps or I understood your question correctly, but maybe using "case" instead of if/elsif/else, the ternary operator, some lazy assignment and some extra validations can give your code a better "rails" feeling.
With lazy assignment I mean that you could wait to initialize sort_code and t_indicator until you actually need to use it or save it.
def sort_code
return self[:sort_code] if self[:sort_code].present?
sort_code = case mail_class
when 'Priority' then '123'
when 'Express'
weight < 1 ? '456' : '789' if weight
end
self[:sort_code] = sort_code
end
That way, sort_code gets initialized right before you need to use it the first time so you can do Mailpiece.new(mail_class: 'Something') and forget about initializing sort_code right away.
The problem would come when you need to save the object and you never called mailpiece.sort_code. You could have a before_validation callback that justs calls sort_code to initialize it in case it wasn't already.
The same can be done for t_indicator.
I would also add some context in your validations
validates_presence_of :weight, if: Proc.new{|record| 'Express' == record.mail_class} #you could add some helper method "is_express?" so you can just do "if: :is_express?"
validates_presence_of :sort_code, if: Proc.new{|record| 'Priority' == record.mail_class or 'Express' == record.mail_class && record.weight.present?}
Sorry if I missunderstood your question, I didn't even use your options haha.

Answer 2

How about:
class Mailpiece
validates_presence_of: :mail_class
validates_presence_of: :weight
validates_presence_of: :sort_code
validates_presence_of: :t_indicator_id
def default_mail_class
'Priority'
end
def default_sort_code
mail_class = mail_class || default_mail_class
if mail_class == 'Priority'
'123'
elsif mail_class == 'Express'
weight < 1 ? '456' : '789'
end
end
end
Then, when you needed to figure out t_indicator, just do it as-needed:
def is_foobar_indicator?
sort_code || default_sort_code == '456'
end
def t_indicator
indicator_params = {name: is_foobar_indicator? ? 'foobar' : 'blah'}
Indicator.find_by(indicator_params)
end
So you can still have the validation on sort_code (assuming that is user provided) but still use defaults when looking at t_indicator. I don't know how complicated the rest of your model is, but I would suggest not looking up values until you need them. Also, after_initialize is risky because it runs your code exactly where it claims - after every initialize, so if you run a query for N items but do nothing but find on them, or wind up not using the defaults you're setting, after_initialize runs N times for nothing.