# Checking my has\_many :through relationships **URL:** \ **Category:** Rails\ **Created:** [March 22, 2009, 7:09pm UTC](https://www.ruby-forum.com/t/checking-my-has-many-through-relationships/163588 "2009-03-22T19:09:33Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![snowbird122](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/c68b51/32.png) [@snowbird122](https://www.ruby-forum.com/u/snowbird122)\ **Post date:** [March 22, 2009, 7:09pm UTC](https://www.ruby-forum.com/t/checking-my-has-many-through-relationships/163588/1 "2009-03-22T19:09:33Z")
I have a Cubicle model that will have many Printers, Phones, whatever. In the past, HABTM has sufficied, but each of the joins will need the capability to store additional attributes inside of the respective table. From what I’ve read, this is only a feature of using a join model – has\_many :through it is. I want to be able to do @cubicle.printers, @cubicle.phones, etc. as well as @phone.cubicle, @printer.cubicle, so the relationship needs to be bidirectional. What I have is functioning, but given that this is my first time using has\_many :through, I’d like to run my solution by the group to see if 1. I am setting up the relationships correctly and 2) if there is a better (cleaner?) way. For each join case, I create a model and a table. So for the cubicles \<–\> printers relationship, I have a model cubilces\_printer.rb, a table called cubicles\_printers that has the necessary foreign keys and additional attributes, and establish the relationships as so: CubiclePrinter belongs\_to :cubicle belongs\_to :printer Printer has\_many :cubicles\_printers has\_many :cubicles :through =\> :cubicles\_printers Cubicle has\_many :cubicles\_printers has\_many :printers :through =\> :cubicles\_printers I think this is right, it just feels odd initially building the middle layer model. My brain wants to just say Cubicle has\_many :printers given that the Printer model is already defined and have Rails just know, sort of like HABTM, to look for the join in the cubicles\_printers table. But I guess the difference comes in with the additional model attributes. ---
**Author:** ![snowbird122](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/c68b51/32.png) [@snowbird122](https://www.ruby-forum.com/u/snowbird122)\ **Post date:** [March 22, 2009, 8:49pm UTC](https://www.ruby-forum.com/t/checking-my-has-many-through-relationships/163588/2 "2009-03-22T20:49:16Z")
On Mar 22, 6:08 pm, ericindc [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > I think this is right, it just feels odd initially building the middle > layer model. My brain wants to just say Cubicle has\_many :printers > given that the Printer model is already defined and have Rails just > know, sort of like HABTM, to look for the join in the > cubicles\_printers table. But I guess the difference comes in with the > additional model attributes. I often find that has many through feels awkward when you haven’t quite pinned down what the join model is and have to name it something like CubiclesPrinters (the classic example is having a join model called Subscription between Person and Magazine rather than MagazinesPeople). It obviously doesn’t change what actually happens but finding a good name makes the relationship feel more natural rather than a hoop you jump through to make active record happy Fred ---
**Author:** ![snowbird122](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/c68b51/32.png) [@snowbird122](https://www.ruby-forum.com/u/snowbird122)\ **Post date:** [March 22, 2009, 11:54pm UTC](https://www.ruby-forum.com/t/checking-my-has-many-through-relationships/163588/3 "2009-03-22T23:54:54Z")
I think you’re entirely right. But I struggle to find a meaningful, yet natural-feeling name. But besides the name, it still feels a tad awkward having the join model. It feels unnecessary, though the additional attributes require it. Thanks for the response. On Mar 22, 3:48 pm, Frederick C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)