75

Rails has a has_one :through association that helps set up a one-to-one association with a third model by going through a second model. What is the real use of that besides making a shortcut association, that would otherwise be an extra step away.

Taking this example from the Rails guide:

class Supplier < ActiveRecord::Base has_one :account has_one :account_history, :through => :account end class Account < ActiveRecord::Base belongs_to :supplier has_one :account_history end class AccountHistory < ActiveRecord::Base belongs_to :account end

might allow us to do something like:

supplier.account_history

which would otherwise be reached as:

supplier.account.history

If it's only for simpler access then technically there could be a one-to-one association that connects a model with some nth model going through n-1 models for easier access. Is there anything else to it that I am missing besides the shortcut?

Improve this question
1
  • THANK YOU SO MUCH. I've been struggling for a couple days on trying to get this to work without knowing that i needed the :through directive. All better now. Commented Nov 1, 2020 at 11:32

3 Answers 3

Reset to default
62

  1. Logic, OK it might sound a bit weak for this but it would be logical to say that "I have a supplier who has an account with me, I want to see the entire account history of this supplier", so it makes sense for me to be able to access account history from supplier directly.

  2. Efficiency, this for me is the main reason I would use :through, simply because this issues a join statement rather than calling supplier, and then account, and then account_history. noticed the number of database calls?

    • using :through, 1 call to get the supplier, 1 call to get account_history (rails automatically uses :join to retrieve through account)

    • using normal association, 1 call to get supplier, 1 call to get account, and 1 call to get account_history

That's what I think =) hope it helps!

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

I think the logic argument is pretty valid. Sounds more natural to say, get me this supplier's account history and not supplier's account's history. Very subtle but still easier to remember considering Ruby/Rails philosophy of flowing sentences rather than code. I know we can see the actual DB queries being issued but does Rails specify how these method calls would translate to SQL?
This also avoids violating the Law of Demeter.
@TomCrayford, I don't really see how it does. Doesn't this make the relation less direct?
@JasperKennis the physical relationship is less direct, but assuming other reasons for not directly linking the tables (like the fact that denormalizing supplier_id from account to account_history requires a callback and a small amount more storage space), this makes it so that you don't have to write a chain of methods every time you access account history through a supplier. And if the table in between changes at some later point, you won't have to rewrite method calls throughout your application. You'll only have to change the association(s).
Let's also not forget about avoiding a scenario where you may need to call another class method from within a class, for a very simple operation, and dont want to create an interface or service object for what may be a brutally simple data request. has_one :through is a lot cleaner for performing operations on tertiary relational data, than injecting or instantiating the tertiary class in the calling class.
16

I'm surprised no one has touched on Association Objects.

A has_many (or has_one) :through relationship facilitates the use of the association object pattern which is when you have two things related to each other, and that relation itself has attributes (ie a date when the association was made or when it expires).

This is considered by some to be a good alternative to the has_and_belongs_to_many ActiveRecord helper. The reasoning behind this is that it is very likely that you will need to change the nature of the association or add to it, and when you are a couple months into a project, this can be very painful if the relationship were initially set up as a has_and_belongs_to_many (the second link goes into some detail). If it is set up initially using a has_many :through relationship, then a couple months into the project it's easy to rename the join model or add attributes to it, making it easier for devs to respond to changing requirements. Plan for change.

Improve this answer

Comments

14

  • Inverse association: consider the classic situation user-membership-group. If a user can be a member in many groups, then a group has many members or users, and a user has many groups. But if the user can only be a member in one group, the group still has many members: class User has_one :group, :through => :membership but class Group has_many :members, :through => memberships. The intermediate model membership is useful to keep track of the inverse relationship.

  • Expandability: a has_one :through relationship can easy be expanded and extended to a has_many :through relationship

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.