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! -- Posted via http://www.ruby-forum.com/.
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!-- Posted via http://www.ruby-forum.com/.
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? -- Alex
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?? :-) -- Posted via http://www.ruby-forum.com/.
nat wrote:> 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?? :-) >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
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. -- Posted via http://www.ruby-forum.com/.