Comments and changes to this ticket

I wonder how we could actually handle this. It would mean you'd
have to save the parent before the children in order to be
able to validate the children. So simply calling parent.valid?
would save it and then run the validations on the children. That
all seems very complicated to me.

Also, this should already be tested in the framework and not
something the developer should need to worry about. However, if you
feel there are tests for scenarios missing let me know.

If you still feel a strong need to validate that after creation
the foreign key is set, I would suggest adding an after_save
callback which verifies this and if not rolls back the
transaction.

Is there any update regarding the previous suggestion? (Having
#build_child directly assign the parent to satisfy a
'validates_presence_of :parent without the need for the parent to
already be saved?)

I looked around on the mailing lists and did not see a ticket on
this. It seems like a promising approach, and it would allow for a
resolution to this issue.

Based on the blog feedback, it seems more than a handful of
people do use validates_presence_of :parent_id in their belongs_to
relationship models (I recall it being recommended in Dan Chak's
excellent Enterprise Rails book) and it seems a shame to ask them
to remove or recode that with an after_save callback just so this
new feature can work.

Is there any update regarding the previous suggestion? (Having
#build_child directly assign the parent to satisfy a
'validates_presence_of :parent without the need for the parent to
already be saved?) I looked around on the mailing lists and did not
see a ticket on this. It seems like a promising approach, and it
would allow for a resolution to this issue.

Nope, not that I know of. As I already suggested, open up a new
ticket which requests this, or better yet, attach a patch.

Based on the blog feedback, it seems more than a handful of
people do use validates_presence_of :parent_id in their belongs_to
relationship models (I recall it being recommended in Dan Chak's
excellent Enterprise Rails book) and it seems a shame to ask them
to remove or recode that with an after_save callback just so this
new feature can work.

This has nothing to do with any new feature, it just doesn't
work this way.

There might also be uniqueness conditions that you want to
enforce, but these fail as per the discussion above. For example,
if you were trying to save a course and enrolments and had a
uniqueness condition on enrolments to prevent a student from
enrolling in a course more than once: validates_uniqueness_of
:student_id, :scope => :course_id This validation does
not work when creating a new course (say, the user has
accidentally added the same student twice on the course form they
are submitting). This is an old issue - see: http://dev.rubyonrails.org/ticke...

Basically, it means that accepts_nested_attributes_for is not as
nice and tidy as one would perhaps expect. Validations need to be
handled by the DBMS.

I was bitten by the same problem ( described here http://railsforum.com/viewtopic.php?pid=96990
), and still don't get how to build, in the terms of the above
example, the Person object with Child object in children
association in memory, and then save them with one call.

I.e. get the transaction safety and easier error reporting for
building complex objects.

I think we still need to fix it.
In case of a nested resource with its own form, we might want to
validate that the child does indeed belong to a parent even if its
form is not nested in the parent.
At the very least we need to be able to provide a way to tell
weather we are in the model from a nested form or individual form,
so that we can validate accordingly.
the workaround I currently use in my apps is to assign an attribute
':nest' ( = self, ie, the parent )to each child before validation
on parent and check for it in child