Forum: Ruby on Rails has_many :through query question

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
8217faf2bfdfa7daf10135d41ddd421e?d=identicon&s=25 Jeff Cohen (jeff)
on 2007-01-26 16:59
(Received via mailing list)
I think this is obvious. but for some reason I'm not getting it.

Models: Bicycles, Accessories
Join Model: Upgrades

The idea is that you can upgrade your bike by adding an accessory, and
the upgrade price is often less than the accessory price would normally
be.  So the Upgrades table has id, bicycle_id, accessory_id, and price.


class Bicycle
  has_many :upgrades
  has_many :accessories, :through => :upgrades
end

class Upgrade
  belongs_to :bicycle
  belongs_to :accessory

  # price defined in table
end

Now my question is, I need to query the upgrades for a bicycle for a
specific accessory.

I was doing this:

  accessory = Accessory.find_by_description("headlight")
  bike.upgrades.find_by_accessory_id(accessory.id)

but it seems klunky.  Is there a better way to perform this kind of
lookup?

Thanks
Jeff
83ca41657a99b65d99889abe712ba5e2?d=identicon&s=25 Jason Roelofs (Guest)
on 2007-01-26 17:10
(Received via mailing list)
It seems as bikes can have accessories that may or may not be upgrades,
so:

bike.upgrades.accessories.find_by_description("headlight")

Otherwise, if there are only upgrade accessories, you can bypass a step:

bike.accessories.find_by_description("headlight")

Though in terms of good design (no dependency chaining), it might be a
good
idea to add a method to one of the models to hide this away. Say,
Updgrade#find_accessory_by_description

Jason
Ae37af4ca07c58f33767e934b78f2a04?d=identicon&s=25 redmotive (Guest)
on 2007-01-26 17:12
(Received via mailing list)
Hi Jeff,

So if I am tracking with you here, you are looking for Accessories
associated with a Bicycle as joined by the Upgrades.  You should be
able to just call bicycle.accessories.find(accessory) if you have an
accessory, since Accessories are now associated with the Bicycle object
via the has_many :though declaration.  The has_many :through takes care
of the need to go to the Upgrades object first from Bicycles since you
specified the relationship in the model.

Hope this helps!

C
72eb65fa089082d3bd8b38a5596ad331?d=identicon&s=25 Keynan Pratt (keynan)
on 2007-01-26 17:14
first toss the price and the id columns from your through table. you
never need id and it might be screwing some thing up. the total order
price should be calculated at run time and the accessory price should be
in the accessories table.

second bicycle and accessories should both use has_and_belongs_to_many
for the other with through => Upgrade(s).

now for your question. No this is specific problem so the best way to
handle it is to add a method to your bike model in which you can pass in
"headlight".

def get_accessory(upgrade_type){
 self.upgrades().each() do |up|
   return up if up.description == "headlight"
 end
}

this should cut down your proccessing to as it eliminates a costly DB
query.(assuming there are not a huge amount of upgrades assigned to that
bike)
8217faf2bfdfa7daf10135d41ddd421e?d=identicon&s=25 Jeff Cohen (jeff)
on 2007-01-26 17:24
(Received via mailing list)
On Jan 26, 10:12 am, "redmotive" <c...@redmotive.com> wrote:
> So if I am tracking with you here, you are looking for Accessories
> associated with a Bicycle as joined by the Upgrades.  You should be
> able to just call bicycle.accessories.find(accessory) if you have an
> accessory, since Accessories are now associated with the Bicycle object
> via the has_many :though declaration.  The has_many :through takes care
> of the need to go to the Upgrades object first from Bicycles since you
> specified the relationship in the model.

Almost but not quite - what I need is the Upgrade row, not the
Accessory row, because I need to know the price for the upgrade given
the desired accessory.

So bicycle.accessories.find_by_description("headlight") returns an
Accessory object, but I still don't know the upgrade price.

That's why this is a bit tricky - I want an upgrade row, selected by
the accessory description.  Since the description is not in the join
table, it seems I have to do two lookups - one to find the accessory,
and the other to find the upgrade row given the accessory id (yuck).

Jeff
8217faf2bfdfa7daf10135d41ddd421e?d=identicon&s=25 Jeff Cohen (jeff)
on 2007-01-26 17:31
(Received via mailing list)
On Jan 26, 10:14 am, Keynan Pratt <rails-mailing-l...@andreas-s.net>
wrote:
> first toss the price and the id columns from your through table. you
> never need id and it might be screwing some thing up. the total order
> price should be calculated at run time and the accessory price should be
> in the accessories table.

I have a real join model here, not a simple habtm, because an upgrade
price is different from the normal accessory price.  Sorry if I wasn't
clear about that.

(ID columns never "screw things up", btw).

>
> def get_accessory(upgrade_type){
>  self.upgrades().each() do |up|
>    return up if up.description == "headlight"
>  end
>
> }this should cut down your proccessing to as it eliminates a costly DB
> query.(assuming there are not a huge amount of upgrades assigned to that
> bike)

Actually, self.upgrades will result in a query against the database...
plus you've got another performance hit by iterating through the
objects (I would suggest a .detect here instead of .each, btw).

Thanks anyway
Jeff
87d298ecabf4a78819698a036ce01a1a?d=identicon&s=25 Mark Carey (Guest)
on 2007-01-26 20:46
(Received via mailing list)
It sounds like your model might need abstraction needs some work,
although
more information is needed to know what you are trying to accomplish.
You
might need to sit down and rethink the relationships between the models
and
what information should be in which table.

Why are you using an upgrades table?  Are accessories available as
non-upgrades?  If an accessory is accessed as an upgrade is the
information
different than when as an accessory only?  Is there a reason you don't
want
to put the upgrade fields into your accessory model and bypass the
has_many
:through association completely?

M<><
This topic is locked and can not be replied to.