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,

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.

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