A lot has been posted about validation issues with associations,
however, I don’t see this issue addressed specifically.
ex:
class Foo
has_one :schedule, :dependent => :destroy
validates_presence_of :schedule
class Schedule
belongs_to :foo
validates_presence_of :foo_id
this creates a circular dependency that breaks test frameworks like
pickle and machinist.
At first I was surprised a little that you can contsruct objects with
this constraint
…you can of course with “new” and “save”
…though I it sounds like the destroy will cause a problem. http://mohammed.morsi.org/blog/taxonomy/term/29
is there a workaround for tests?
or is this a bad idea from the start?
Nevertheless, It seems to me that while a noble goal – to validate
both sides of the assoication.
How else to do it?
thanks?
A lot has been posted about validation issues with associations,
however, I don’t see this issue addressed specifically.
ex:
class Foo
has_one :schedule, :dependent => :destroy
validates_presence_of :schedule
class Schedule
belongs_to :foo
validates_presence_of :foo_id
this creates a circular dependency that breaks test frameworks like
pickle and machinist.
At first I was surprised a little that you can contsruct objects with
this constraint
…you can of course with “new” and “save”
…though I it sounds like the destroy will cause a problem. http://mohammed.morsi.org/blog/taxonomy/term/29
is there a workaround for tests?
or is this a bad idea from the start?
It’s a bad idea from the start. Get rid of the validation on the
has_one side.
Nevertheless, It seems to me that while a noble goal – to validate
both sides of the assoication.
How else to do it?
thanks for the quick response…some follow up questions:
why get rid of the validation on the has_one side rather than the
belongs_to?
why do you call it unnecessary?
the requirement that Foo has a schedule (in my example) and vice-versa
seems reasonable.
However, given the above, I don’t see how that works with validations.
How would we satisfy that requirement w/o validations?
perhaps a factory method?
or using a callback on create?
where we create a default schedule.
thanks for the quick response…some follow up questions:
why get rid of the validation on the has_one side rather than the
belongs_to?
On the belongs_to side, you can check for a foreign key within the
object, which is straightforward. There’s no simple way to do it from
the has_one side.
why do you call it unnecessary?
Because it serves no actual purpose. It does not gain you any
additional functionality or validation.
the requirement that Foo has a schedule (in my example) and vice-versa
seems reasonable.
However, given the above, I don’t see how that works with validations.
How would we satisfy that requirement w/o validations?
Since a Foo is only ever going to have one Schedule, you can create the
schedule in Foo.new or before_save, or when Foo#schedule is first
called.
In general, you only need validation on the belongs_to side.
perhaps a factory method?
or using a callback on create?
where we create a default schedule.
Yes, a callback is a good approach. Also consider merging the two
tables – has_one is a bit smelly.