Forum: Ruby on Rails limits of has_and_belongs_to_many

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.
6dfd01c549aa33a158730c7d9f7064cc?d=identicon&s=25 Da Plutes (plutes)
on 2006-01-19 04:12
I'm experimenting with Rails on the Recipes example first before I dive
into applying it to my intended application. I'm exploring which will be
more work: to rename all the primary id's in the legacy database, or to
work around the fact that the primary id's are not called 'id' within
RoR instead.

I've been successful in using a join table with two fields named
'recipe_id' and 'tag_name' to relate a table called Recipes with a table
called Taggs, using this model:

class Recipe < ActiveRecord::Base
has_and_belongs_to_many :taggs,  :join_table => "recipes_tagnames" ,
:association_foreign_key => "tag_name"
end

In this case both Recipes and Taggs have a field called 'id' as their
primary key, i.e., they are being joined by Recipes.id =
Recipes_Tagnames.recipe_id AND Recipes_Tagnames.tag_name = Taggs.id.

This works just fine, however for the legacy database in my intended
application I prefer not to rename all of the primary id's to 'id' just
to get Rails' slick conventions to work.

Apparently, according the current syntax, has_and_belongs_to_many cannot
be made to work when either of the databases that are to be joined have
their primary id named to something other than 'id'.  Is this correct?
It appears that the options only provide additional flexibility within
the join table.

Gracias!
47050330a91f673338637da401fca0fb?d=identicon&s=25 nat (Guest)
on 2006-01-19 07:54
I wanna to hear the answer to this too. Our data models have been finely
tuned and I doubt I'll get clearance to tweak even field names to make
my coding life easier - and if that's what Ruby needs to rock & roll,
then one of my colleagues has openly wondered if its ready for prime
time. But I'm still giving it a go.

nat


dr plutes wrote:
> I'm experimenting with Rails on the Recipes example first before I dive
> into applying it to my intended application. I'm exploring which will be
> more work: to rename all the primary id's in the legacy database, or to
> work around the fact that the primary id's are not called 'id' within
> RoR instead.
>
> I've been successful in using a join table with two fields named
> 'recipe_id' and 'tag_name' to relate a table called Recipes with a table
> called Taggs, using this model:
>
> class Recipe < ActiveRecord::Base
> has_and_belongs_to_many :taggs,  :join_table => "recipes_tagnames" ,
> :association_foreign_key => "tag_name"
> end
>
> In this case both Recipes and Taggs have a field called 'id' as their
> primary key, i.e., they are being joined by Recipes.id =
> Recipes_Tagnames.recipe_id AND Recipes_Tagnames.tag_name = Taggs.id.
>
> This works just fine, however for the legacy database in my intended
> application I prefer not to rename all of the primary id's to 'id' just
> to get Rails' slick conventions to work.
>
> Apparently, according the current syntax, has_and_belongs_to_many cannot
> be made to work when either of the databases that are to be joined have
> their primary id named to something other than 'id'.  Is this correct?
> It appears that the options only provide additional flexibility within
> the join table.
>
> Gracias!
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-01-19 10:45
(Received via mailing list)
nat wrote:
> I wanna to hear the answer to this too. Our data models have been finely
> tuned and I doubt I'll get clearance to tweak even field names to make
> my coding life easier - and if that's what Ruby needs to rock & roll,
> then one of my colleagues has openly wondered if its ready for prime
> time. But I'm still giving it a go.
Is the set_primary_key method not doing the do?
47050330a91f673338637da401fca0fb?d=identicon&s=25 nat (Guest)
on 2006-01-19 15:57
Alex Young wrote:
> nat wrote:
>> I wanna to hear the answer to this too.
> Is the set_primary_key method not doing the do?

How do the naming conventions work with a different primary key for
things like has_and_belongs_to_many/has_many/belongs_to?  Say in the
recipes example above, if recipes.id were renamed to R_ID and made
primary w/ set_primary_key. Let's play who wants to be a rails wonk:
what foreign key would rails try to use in recipes_tagnames instead of
recipe_id?  (a) recipe_R_ID, (b) R_ID, (c) recipe_r_id, or (d)
recipe_id?  I'm guessing (d)... (do i get to move on to the next round
regis?? :-)
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-01-19 16:38
(Received via mailing list)
nat wrote:
> of recipe_id?  (a) recipe_R_ID, (b) R_ID, (c) recipe_r_id, or (d)
> recipe_id?  I'm guessing (d)... (do i get to move on to the next
> round regis?? :-)
>

Yup...  According to the docs:

> :foreign_key - specify the foreign key used for the association. By
> default this is guessed to be the name of this class in lower-case
> and "_id" suffixed. So a Person class that makes a
> has_and_belongs_to_many association will use "person_id" as the
> default foreign_key.

--
Alex
6dfd01c549aa33a158730c7d9f7064cc?d=identicon&s=25 Da Plutes (plutes)
on 2006-01-19 17:00
A minor suggestion for the rails developers - might be nice to have
something called set_default_foreign_key.  So if table People has
primary key Pers_ID and all other tables that link to it also use
Pers_ID to do so, if the People model is told "set_default_foreign_key
Pers_ID" then thereafter for things like has_many or habtm it would
guess that the foreign key is Pers_ID rather than people_id.  Hmmm..
perhaps the model could also correctly guess the proper
foreign_association_key as well for other models that have had a their
own default foreign key specified by set_default_foreign_key.
This topic is locked and can not be replied to.