Polymorphic association and STI (again..)

[runlevel5]

I have a case of polymorphic association and STI here.

# app/models/car.rb
class Car < ActiveRecord::Base
  belongs_to :borrowable, :polymorphic => true
end

# app/models/staff.rb
class Staff < ActiveRecord::Base
  has_one :car, :as => :borrowable, :dependent => :destroy
end

# app/models/guard.rb
class Guard < Staff
end

In order for the polymorphic assocation to work, according to the API documentation on Polymorphic Assocation, http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html#label-Polymorphic+Associations that I have to set borrowable_type to the base_classof STI models, that is in my case is Staff.

The question is: Why doesn't it work if the borrowable_type set to STI class? Is this something could be worked on? Or is it not supposed to be the way at first place?

Some test to prove it:

# now the test speaks only truth

# test/fixtures/cars.yml
one:
  name: Enzo
  borrowable: staff (Staff)

two:
  name: Mustang
  borrowable: guard (Guard)

# test/fixtures/staffs.yml
staff:
  name: Jullia Gillard

guard:
  name: Joni Bravo
  type: Guard 

# test/units/car_test.rb

require 'test_helper'

class CarTest < ActiveSupport::TestCase
  setup do
    @staff = staffs(:staff)
    @guard = staffs(:guard) 
  end

  test "should be destroyed if an associated staff is destroyed" do
    assert_difference('Car.count', -1) do
      @staff.destroy
    end
  end

  test "should be destroyed if an associated guard is destroyed" do
    assert_difference('Car.count', -1) do
      @guard.destroy
    end
  end

end

But it seems to be true only with Staff instance. The results are:

# Running tests:

F.

Finished tests in 0.146657s, 13.6373 tests/s, 13.6373 assertions/s.

  1) Failure:
test_should_be_destroyed_if_an_associated_guard_is_destroyed(CarTest) [/private/tmp/guineapig/test/unit/car_test.rb:16]:
"Car.count" didn't change by -1.
<1> expected but was
<2>.

Thanks

[al2o3cr]

This behavior is by design - the _type column stores enough information to figure out which database table to use.

Storing the full STI type means that a bit of information (the specific type of the referenced object) is now stored in two places: the association's _type field, and the record's own type column. This is generally regarded as a bad thing.

BTW, if only Staff are going to be interacting with the Car model a polymorphic association isn't required - you can assign a Guard to a belongs_to :staff association without causing any problems.

[runlevel5]

@al2o3cr: thanks for the answer. I can see storing the class information in both polymorphic type and _type attributes is overkill, yet I think if such cases like this occur, the polymorphic should be consistent with the _type.

The example I give you is very simple, there is often that more than one subclasses on a class.

If this is the way it is, I guess I can close the issue now.

[ahawkins]

@rafaelfranca You can close this. Seems @JONESLEE85 said he would but has been lost to the sands of time.

[rafaelfranca]

I'm closing this now. If this is still an issue, please reopen it.

[januszm]

@rafaelfranca @JONESLEE85 @al2o3cr the https://rubygems.org/gems/store_base_sti_class gem exists just to resolve this issue (100k+ downloads), I'm upgrading it to support Rails 5 now. I'm wondering if you still agree with the statement that it should not be handled by ActiveRecord.

Perhaps users of store_base_sti_class gem are doing something wrong when they design associations in their apps? Test cases for that gem look reasonable though. As far as I remember in my case it was all about avoiding additional db query just to learn about the actual class in associated models.

Just in case it helps, I have it in one project with the following scenario:
Company and User models serve as base classes. Company has_many users.
They're both subclassed by BuyerCompany, SellerCompany and BuyerUser, SellerUser (names changed).
All Company-like subclasses can have locations (Location belongs_to :locatable, polymorphic: true).
It seems that the gem mentioned above is used to store company_id | company_type info in users table and locatable_type | locatable_id for locations. Without the gem I'd just have Company (instead of the actual subclass) in all those _type columns.

[matthewd]

@januszm sorry, the history here is long and a bit hard to follow...

Do you have an example (ideally, using this template), that shows a simple question on the Relation API, where store_base_sti_class saves a query?

I had a quick look through the gem's tests, but it was hard to pick out the interesting behaviour from the (very reasonable and necessary, of course) tests ensuring "normal" stuff was still working, or that made specific assertions on the contents of the *_type column.

Ultimately, any database normalization decision is inherently a trade-off between duplication of data and the need for additional queries/joins to retrieve it, so I don't see a fundamental change in our future -- but I'd like to properly understand the concern first.

(To be clear: I do know what is/isn't ending up in the database column under each scheme.. it's the higher level, application-observable, behaviour I'd like to understand more.)

[januszm]

@matthewd thank you for quick reply! I'm not the original author of this gem and I'm not sure if I'll be able to give you best example.

I'm updating a legacy (yeah) project which uses it and it might take a while before I determine what was the exact reason for adding that gem (ie. storing the actual class for polymorphic associations with STI and what is the impact of this on the app behaviour). Perhaps others, who were recently interested in updating the gem for Rails 5 could tell you more: @n-rodriguez @alejandrodevs @edwardmp could you give us more details/examples why this is useful?