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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
