To further clarify (and answer one of the questions above): You must specify the :primary_key option to #has_one (and #has_many) in your model definition if, and only if, the table of the resource that "owns" the other record (i.e., the table associated w/the model that contains the #has_one method call) doesn't use "id" for its own primary key. The same applies to #belongs_to, :primary_key is only needed when the "owning" resource's table doesn't use "id". So, if a post has many comments and you're hooking the relationships up, as long as the posts table uses "id" for its primary key, then neither the #has_many inside the Post class or the #belongs_to inside the Comment class will need the :primary_key option.
Similarly, you must specify the :foreign_key options to #belongs_to, #has_many and #has_one if and only if the "owned" resource (the one that actually has the foreign key column) doesn't follow the rails convention for its foreign key column name (lower-case and underscored version of the resource's class name, which is ideally the same as the singular version of the table name, all with the "_id" suffix). So, as long as the table backing the Comment class (even if the table has a wonky name and #set_table_name is used) has a "post_id" column then :foreign_key options won't be needed on any of the relationships (on the owner or ownee). In the OP's situation, the owning table used "id" for its primary key (people table for the Person class). Thus no :primary_key options were needed anywhere. Likewise, the owned tables (instructors for the Instructorclass (and the other one...)) used the rails convention for the foreign key names, so :foreign_key options were unnecessary. All this regardless of the fact that the OP *happened* to be re-using the primary key for the foreign key in the owned resource tables. Now, if one of the owned resources later needed to "own" something themselves (like an instructor having many "students" for example) then ** those** relationships would have required :primary_key options since "id" wasn't the primary key name. Now, to answer one of the questions posed further above... The :primary_key option in migrations vs. the #primary_key method available on the table definition object inside your #create_table call are, for most part, redundant. Also, when it comes to migrations that create new tables, I personally see no need for both and would just always use the :primary_keyoption to #create_table. However, if you created a table long ago and for some reason it had no primary key (imagine an old database or a table that used to just be a join table). You might want to "add" a primary key in a new migration. In this case, you definitely won't be using the :primary_key option to #create_tablein your migration. You'll be modifying the table to add a new primary key column. Now, the presence of the #primary_key method on a table definition would make sense if this worked: class AddIdToOldItems < ActiveRecord::Migration def self.up change_table :old_items do |t| t.primary_key :id # other changes ... end end def self.down change_table :old_items do |t| # other changes ... t.remove :id end end end However, on a quick test, #primary_key isn't defined in this context. Instead, you have to use one of: change_table :old_items do |t| t.column :id, :primary_key end Or just add_column :students, :id, :primary_key So, I guess having #primary_key available in the context in creating a new table is just for extra options? Anyone else care to comment on this? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.