[PATCH] Polymorphic has_one and has_many should set proper polymorphic_type in case of STI

Set proper type field for STI models with polymorphic association defined in parent

In existing test case, it uses posts(:thinking) which has type "SpecialPost" defined in fixture, but test checks for type "Post".

This is expected behavior. There should be no problems with checking for the base class.

Just wanted to point out a valid usecase where this could make a difference.

Thanks, Pratik

I can't see why this should be the "expected behaviour". Ofcourse the record can be found through either but why not use the name that more closely identifies what is being looked for?

Replying to tarmo:

The purpose of the polymorphic_type field is to identify the table the polymorphic_id foreign key points into. If that table is an STI table, then you should use the base class for that table as the polymorphic_type. If someone mutated a record in that table to be a different class (difficult but not impossible to pull off), then using the concrete class as the poly type would screw you up bigtime. There are probably other implications too, but that's enough for me now.

Ok, I can agree with this.

As for lifofifo use case, why not validate against the actual attachment.attachable.class? Yes it would create an additional SQL request if attachable is not yet loaded but it's not that bad, is it?

The correct type must be stored, or destroy() may fail. It did that in Rails 1.2, even though a loop through the children worked fine. Is this fixed in Rails 2?

http://pastie.caboo.se/129651

Replying to hasmanyjosh:

Replying to tarmo: The purpose of the polymorphic_type field is to identify the table the polymorphic_id foreign key points into. If that table is an STI table, then you should use the base class for that table as the polymorphic_type. If someone mutated a record in that table to be a different class (difficult but not impossible to pull off), then using the concrete class as the poly type would screw you up bigtime. There are probably other implications too, but that's enough for me now.

But what about the case where the base class is abstract?

I've been banging my head against this for hours. I finally applied the patches from #6485 and everything works great. Here's my example, a case where there is an abstract, base class for the poly:

http://pastie.caboo.se/170166

Before the patch, calls to Buyer.find(:first).users would return an empty array because it was building it based upon the base class: Account instead of the actual class as stored in the users table.

(and actually, I had to add: :dependent => :destroy to the Account class to get it to work right: Buyer.find(:first).destroy => destroys the buyer account plus all user accounts associated with that buyer via the account_id and account_type fields)