So a while back, I stumbled over here:
http://dev.rubyonrails.org/ticket/8841
Turns out I was having problems because what seemed to me a bug: with
a polymorphic relationship that also uses STI, Rails stores the type
field as the base class, not as the STI child class.
I can see the argument that this is “right” because that’s where the
table name comes from. But here’s my major problem: if you don’t store
the actual STI class, how can you possibly recreate it? You can always
go down the chain, but can’t go up. I.e. a child class can use
class.base_class to get the base, but if you are at the base class,
you can’t “infer” the proper child class.
For example, in Pratik’s example here: http://pastie.org/75480 if you
set up that code (with DB tables), then do:
video = Video.create
attachment = Attachment.create
video.attachment = attachment
The “attachable_type” field in the “attachments” table is: “Asset”,
and not “Video”.
So later, if you do:
Attachment.find(x).attachable # => Asset(…)
I.e. it returns an Asset object, and NOT a Video object.
I just tried this in Rails 2.1.0.
I’m trying to figure out if I’m missing something or if there is
legitimately a concern here. Wouldn’t you want to store “Video” for
“attachable_type”? What is the argument for storing “Asset”?
And it gets really messy for me because I have some code where the
base class is abstract. The subclasses using STI each have their own
table. So in Pratik’s example, Asset wouldn’t have an “assets” table.
But there’d be a “photos” table, for example. And without getting the
right class in the “attachable_type” field, you get SQL errors for non-
existent tables.
Can anyone help shed some light on this? Or do I need to continue the
monkeypatching I did with Rails 2.0.2 (which is when I discovered
this)
Thanks!
-Danimal