To try and ease my pain, I am refactoring a Rails 2.3.5 application using Hobo from multiple tables to a single table. I’m talking about models which are essentially the same: companies, people and employees. I went from this:
1 class Company < ActiveRecord::Base 2 has_many :employees 3 has_many :people, :through => :employees 4 end 5 6 class Person < ActiveRecord::Base 7 has_many :employees 8 has_many :companies, :through => :employees 9 end 10 11 class Employee < ActiveRecord::Base 12 belongs_to :company 13 belongs_to :person 14 end
To an STI-enabled class hierarchy:
1 class Addressee < ActiveRecord::Base 2 self.abstract_class = true 3 end 4 5 class Company < Addressee 6 has_many :employees 7 has_many :people, :through => :employees 8 end 9 10 class Person < Addressee 11 has_many :employees 12 has_many :companies, :through => :employees 13 end 14 15 class Employee < Addressee 16 belongs_to :company 17 belongs_to :person 18 end
Can you spot the mistake? Here’s where it breaks down:
1 $ script/console 2 > PersonAddressee.count 3 SQL (9.9ms) SELECT count(*) AS count_all FROM "addressees" 4 => 10231
When the classes are defined with abstract_class? set to true, calling Company#count executes the following:
- ActiveRecord
Company#superclass, which answersAddressee - ActiveRecord calls
Addressee#abstract_class?, which answerstrue - Because
Company#base_class == Company#superclass, no STI is involved, and ActiveRecord queries theaddresseestable with no STI hints (type column).
When removing the abstract class declaration, here’s how it works:
- ActiveRecord
Company#superclass, which answersAddressee - ActiveRecord calls
Addressee#abstract_class?, which answersfalse - ActiveRecord
Addressee#superclass, which answersActiveRecord::Base - Because
Company#base_class != Company#superclass, STI is involved and ActiveRecord adds the type hint to theaddresseestable query.
The documentation is quite clear though:
abstract_class?()
Returns whether this class is a base AR class. If A is a base class and B descends from A, then B.base_class will return B.
The documentation on #base_class is much better though:
base_class()
Returns the base AR subclass that this class descends from. If A extends AR::Base, A.base_class will return A. If B descends from A through some arbitrarily deep hierarchy, B.base_class will return A.
And current HEAD documentation is the best of them all:
base_class()
Returns the base AR subclass that this class descends from. If A extends AR::Base, A.base_class will return A. If B descends from A through some arbitrarily deep hierarchy, B.base_class will return A.
If B < A and C < B and if A is an abstract_class then both B.base_class and C.base_class would return B as the answer since A is an abstract_class.
Luckily, I found this before users got a chance to report bugs. And no, I would never have thought to add a test for this: I’m not in the habit of testing base ActiveRecord functionality.
