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
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”
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.