Running into an interesting problem that at first glance appears to be a
bug in the AR association code. However, it’s explicitly coded this way
so I’m not so sure.
I have some code like this:
class Address < ActiveRecord::Base
belongs_to :addressable, :polymorphic => true
end
class Person < ActiveRecord::Base
has_many :addresses, :as => :addressable, :dependent => :destroy
end
class Member < Person
end
Adding an Address to a Member results in the addressable_type column
equaling “Person” when it should be “Member”. Looking in
ActiveRecord::Associations::AssociationProxy#set_belongs_to_association_for
and ActiveRecord::Associations:: HasManyAssociation#construct_sql it’s
clear why.
From
ActiveRecord::Associations::AssociationProxy#set_belongs_to_association_for:
record["#{@reflection.options[:as]}_type"] =
@owner.class.base_class.name.to_s
Removing the call to base_class results in the behavior I expected. I
did this by patching the two classes at runtime from a file in lib/.
I guess my question is, are my expectations wrong here or is this a bug?
The inclusion of base_class strikes me as something someone meant to do.
Thanks,
Rich Cavanaugh
On Monday, July 31, 2006, at 4:04 AM, Rich Cavanaugh wrote:
class Person < ActiveRecord::Base
on_for
did this by patching the two classes at runtime from a file in lib/.
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
I ran into this too. I also noted that if you manually change the
‘type’ column to match the subclass name, things seem to work fine.
It does really mess with some functionality in acts_as_taggable if your
tagged object is STI. It’s probably worth running the core AR tests
against your patched version to see if anything breaks.
_Kevin
www.sciwerks.com
On Monday, July 31, 2006, at 12:53 AM, bacchusrx wrote:
There’s more to the change than simply assigning the real class name
and I’ve been meaning to make a patch, but I haven’t gotten the chance
yet. There’s probably some reason for the way things are, but it’s
eluded me thus far 
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
It might be worth inquiring on the rails core list about this.
_Kevin
www.sciwerks.com
On 31 Jul 2006 04:25:44 -0000, Kevin O.:
I ran into this too. I also noted that if you manually change the
‘type’ column to match the subclass name, things seem to work fine.
It does really mess with some functionality in acts_as_taggable if your
tagged object is STI. It’s probably worth running the core AR tests
against your patched version to see if anything breaks.
I’ve also had to make similar changes while working on a recent app.
There’s more to the change than simply assigning the real class name
instead of the base class name.
You also have to change the SQL generated by, eg,
ActiveRecord::Assocations#association_join. Otherwise, using your
associations as includes in find() won’t work anymore. Instead, the
join condition should look like the SQL generated by
ActiveRecord::Base#type_condition. If you simply use the real class
name there, subclasses of your subclass won’t be included.
The modifications to AR that I’m using pass all the existing tests,
and I’ve been meaning to make a patch, but I haven’t gotten the chance
yet. There’s probably some reason for the way things are, but it’s
eluded me thus far 