Validating both sides of a has_one relationship breaks pickle/machinist tests

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?

Doug wrote:

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?

Don’t. It’s unnecessary.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

thanks?

thanks for the quick response…some follow up questions:

  1. why get rid of the validation on the has_one side rather than the
    belongs_to?

  2. 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.

thinking out loud here…

thanks again.

Doug wrote:

thanks for the quick response…some follow up questions:

  1. 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.

  1. 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.

thinking out loud here…

thanks again.

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs