
Unexpected behavior with subclassed associations
Reported by Robert Sköld | January 20th, 2010 @ 12:15 PM
Here's an example of the issue: https://gist.github.com/31594a7c27768a9dc879
The problem seems to be that because it's subclassed it seems to be associated with both of the "has 1"s even though it's only been set to one of them.
Comments and changes to this ticket
-
Jonathan Stott (namelessjon) January 20th, 2010 @ 12:35 PM
- State changed from new to not-applicable
This is due to the lack of a discriminator property in the models.
-
Robert Sköld January 21st, 2010 @ 03:32 AM
I have an updated revision of that example: https://gist.github.com/31594a7c27768a9dc879/39e03de014b98c0c7e63ee...
Now, even with a Discriminator, it still sets both of the association properties.
The only difference in the example (besides adding a Discriminator) is that instead of setting only the Baby (the superclass) I set only the Child (the subclass) and in the queries it seems that the discriminator looks for both 'Baby' and 'Child' as type. Is this the expected behavior? Would the proper implementation be to use two separate subclasses instead of the "original" model and it's subclass?
-
Jonathan Stott (namelessjon) January 21st, 2010 @ 07:03 AM
I think that is the expected behaviour. It's single table inheritance, so every Child instance should also act like a Baby instance. The Child might have more behaviour and more properties, but it should also act like a Baby.
Child.new.is_a?(Baby) #=> true
So any subclass of Baby is valid for
has 1, :baby
. To get the behaviour you want, you'll need two subclasses.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »