For the situation described in this thread where your Person class's #has_one :instructor refers to another class (and table) that in fact HAS a column named "person_id" then there is no need to provide the :primary_key option, as this is what it will infer by default.
However, in even weirder situations (like mine for instance where I'm connecting ActiveRecord to an old database that doesn't come close to following the rails conventions), it is useful. Example (similar to what I have to deal with): table: tblUser primary key: UserID table: tblComments primary key: ID # note the inconsistencies I have to deal with foreign key (to tblUser record): PosterID Here, "comments" belong to "users" (a user has_many comments). My models look like this: class User < ActiveRecord::Base set_table_name "tblUser" set_primary_key "UserID" has_many :comments, :primary_key => "UserID", :foreign_key => "PosterID" end class Comment < ActiveRecord::Base set_table_name "tblCommants" set_primary_key "ID" belongs_to :user, :primary_key => "UserID", :foreign_key => "PosterID" end This is an example when you need to use the :primary_key options (and :foreign_key as well). This is because there is NO way rails can infer these names otherwise. However, despite my schema "sucking" (in rails terms) I manage to otherwise use ActiveRecord quite nicely. Now, just because this is possible, doesn't mean I'd ever choose to go against conventions. It is beautiful when you can just rely on the defaults and let the rails magic fly! -- 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.
