Limits of has_and_belongs_to_many

Rails
1

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!

2

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!

3

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?

4

Alex Y. 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, © recipe_r_id, or (d)
recipe_id? I’m guessing (d)… (do i get to move on to the next round
regis?? :slight_smile:

5

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.

6

nat wrote:

of recipe_id? (a) recipe_R_ID, (b) R_ID, © recipe_r_id, or (d)
recipe_id? I’m guessing (d)… (do i get to move on to the next
round regis?? :slight_smile:

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