[PATCH] validates_associated fails when associated id is incorrect

See the note in the validates_associated documentation:

NOTE: This validation will not fail if the association hasn’t been assigned. If you want to ensure that the association is both present and guaranteed to be valid, you also need to use validates_presence_of.

The documentation does not indicate that the validation will fail if the foreign key points to an invalid record number.

For example, if you create a class like...

class Item < AR:Base
  belongs_to :thing
end

if 'thing_id' is set to 1000 without a corresponding record (id=1000) in the 'things' table, the validates_associated will not indicate an invalid association.

This appears like incorrect behavior to me as it appears as if the association is assigned, but the associated object does not exist. This should respond as an invalid association.

Validates_presence_of will not detect this problem since the foreign key is not empty.

I am currently testing a plugin that corrects this behavior.

validates_associated plugin

I don't understand why this works this way.

Why is the ID not validated to be correct? Can someone please explain this?

Are we supposed to always assign the associated object instead of assigning the FK ID?

If so, what is the point of validating it? The only thing the validation will catch is if you create a new associated object instead of retrieving it from the database, and it fails to save.

Typical program flow is something like:

• 'edit' action (or 'new')
• possible FK objects loaded from database into instance var
• 'edit' form displays a SELECT tag created from possible FK objects
• data posted from form (SELECT tag posts the ID of the selected FK object)
• 'update' action (or 'create')
• assign params (including the FK ID) to new object or use create or something
• save

If I have to load the associated object from the DB in my 'update' action, and then assign it to association in the object I'm updating, why bother to do validation? Heck I just retrieved it from the database, it better be valid (concurrency issues aside).

Plus, why force me to load the object from the database? I should just assign the ID (that's what I have anyway) and let Rails load it when it checks the association for validity.

I think this should be included in core.

Would the submitter consider converting their plugin into a patch and include test cases?

yes, I'll do just that.

Would the submitter consider converting their plugin into a patch and include test cases?

I've converted the plugin to a patch. In the process I uncovered some problems with the unit tests for ActiveRecord and submitted Ticket #8218. This patch doesn't test correctly unless the patch in Ticket #8218 is applied.

Ticket #8461 includes a documentation patch to help steer others away from this confusion.

I noticed using this patch with ActiveRecord 1.14.4 (Rails 1.1) there is a small problem. I had to change the line

class_to_check = reflection.options[:polymorphic] ? record.send(reflection.options[:foreign_type]).constantize : reflection.active_record

to read

class_to_check = reflection.options[:polymorphic] ? record.send(reflection.options[:foreign_type]).constantize : reflection.klass

otherwise it searches in the wrong table for the association.

+1.

This change needs to make it into core. Right now validates_associated is not only damn near useless, but doesn't even validate what the name implies it does.

Replying to stouset:

What's the status of this?

I'm also still curious about this. It looks to me like the behavior is still as described above - now in 2.1.

If this doesn't deserve being included in core - what is the reason? Are we simply, grossly misunderstanding the intent of validates_associated?