Rails - Jul 2006 - Polymorphic associations and single table inheritance

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

-- 
Posted via http://www.ruby-forum.com/.

On Monday, July 31, 2006, at 4:04 AM, Rich Cavanaugh
wrote:
>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_associati
>on_for
>and ActiveRecord::Associations:: HasManyAssociation#construct_sql
it''s
>clear why.
>
>>From
>ActiveRecord::Associations::AssociationProxy#set_belongs_to_associati
>on_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
>
>--
>Posted via http://www.ruby-forum.com/.
>_______________________________________________
>Rails mailing list
>Rails@lists.rubyonrails.org
>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

-- 
Posted with http://DevLists.com.  Sign up and save your mailbox.

On 31 Jul 2006 04:25:44 -0000, Kevin Olbrich:
> 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 ;)

On Monday, July 31, 2006, at 12:53 AM, bacchusrx wrote:
>On 31 Jul 2006 04:25:44 -0000, Kevin Olbrich:
>> 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 ;)
>_______________________________________________
>Rails mailing list
>Rails@lists.rubyonrails.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
It might be worth inquiring on the rails core list about this.

_Kevin
www.sciwerks.com

-- 
Posted with http://DevLists.com.  Sign up and save your mailbox.