Best practices for multiple associations with the same class in Rails? - ruby-on-rails

Question

I think my question is best described as an example. Let's say I have a simple model called "Thing" and it has a few attributes that are simple data types. Something like...
Thing
- foo:string
- goo:string
- bar:int
That isn't hard. The db table will contain three columns with those three attributes and I can access them with something like #thing.foo or #thing.bar.
But the problem I'm trying to solve is what happens when "foo" or "goo" can no longer be contained in a simple data type? Assume that foo and goo represent the same type of object. That is, they are both instances of "Whazit" just with different data. So now Thing might look like this...
Thing
- bar:int
But now there is a new model called "Whazit" that looks like this...
Whazit
- content:string
- value:int
- thing_id:int
So far this is all good. Now here is where I'm stuck. If I have #thing, how can I set it up to refer to my 2 instances of Whazit by name (For the record, the "business rule" is that any Thing will always have exactly 2 Whazits)? That is, I need to know if the Whazit I have is basically foo or goo. Obviously, I can't do #thing.foo in the current setup, but I'd that is ideal.
My initial thought is to add a "name" attribute to Whazit so I can get the Whatzits associated with my #thing and then choose the Whazit I want by name that way. That seems ugly though.
Is there a better way?

Answer 1

There are a couple of ways you could do this. First, you could set up two belongs_to/has_one relationships:
things
- bar:int
- foo_id:int
- goo_id:int
whazits
- content:string
- value:int
class Thing < ActiveRecord::Base
belongs_to :foo, :class_name => "whazit"
belongs_to :goo, :class_name => "whazit"
end
class Whazit < ActiveRecord::Base
has_one :foo_owner, class_name => "thing", foreign_key => "foo_id"
has_one :goo_owner, class_name => "thing", foreign_key => "goo_id"
# Perhaps some before save logic to make sure that either foo_owner
# or goo_owner are non-nil, but not both.
end
Another option which is a little cleaner, but also more of a pain when dealing with plugins, etc., is single-table inheritance. In this case you have two classes, Foo and Goo, but they're both kept in the whazits table with a type column that distinguishes them.
things
- bar:int
whazits
- content:string
- value:int
- thing_id:int
- type:string
class Thing < ActiveRecord::Base
belongs_to :foo
belongs_to :goo
end
class Whazit < ActiveRecord::Base
# .. whatever methods they have in common ..
end
class Foo < Whazit
has_one :thing
end
class Goo < Whazit
has_one :thing
end
In both cases you can do things like #thing.foo and #thing.goo. With the first method, you'd need to do things like:
#thing.foo = Whazit.new
whereas with the second method you can do things like:
#thing.foo = Foo.new
STI has its own set of problems, though, especially if you're using older plugins and gems. Usually it's an issue with the code calling #object.class when what they really want is #object.base_class. It's easy enough to patch when necessary.

Answer 2

Your simple solution with adding a "name" doesn't need to be ugly:
class Thing < ActiveRecord::Base
has_one :foo, :class_name => "whazit", :conditions => { :name => "foo" }
has_one :goo, :class_name => "whazit", :conditions => { :name => "goo" }
end
In fact, it's quite similar to how STI works, except you don't need a separate class.
The only thing you'll need to watch out for is setting this name when you associate a whazit. That can be as simple as:
def foo=(assoc)
assos.name = 'foo'
super(assoc)
end