Forum: Ruby on Rails AR::migration - how to change the primary key

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
carl (Guest)
on 2005-11-16 22:34
(Received via mailing list)
What if I don't want AR to automatically create an integer id for a
table's primary key?  For example, if I have a habtm connecting table
I want the primary key to cover all columns in the table?  I don't see
any info about this in the docs.  Is the only way of doing this to put
in an execute rule to manually drop the previously created primary key
and create my own?  It seems like this is a common enough thing that
it should be added as an option to create_table.

Thanks,
Carl
jamis (Guest)
on 2005-11-16 22:49
(Received via mailing list)
On Nov 16, 2005, at 1:31 PM, Carl Y. wrote:

> What if I don't want AR to automatically create an integer id for a
> table's primary key?  For example, if I have a habtm connecting table
> I want the primary key to cover all columns in the table?  I don't see
> any info about this in the docs.  Is the only way of doing this to put
> in an execute rule to manually drop the previously created primary key
> and create my own?  It seems like this is a common enough thing that
> it should be added as an option to create_table.

It is:

   create_table :join_table, :id => false do |t|
     ...
   end

- Jamis
carl (Guest)
on 2005-11-16 23:01
(Received via mailing list)
Great, thanks for the help!
jamis (Guest)
on 2005-11-16 23:25
(Received via mailing list)
On Nov 16, 2005, at 2:00 PM, Carl Y. wrote:

> Great, thanks for the help!

Not a problem. Also, in case anyone else finds themselves in a
similar boat, wondering what create_table really can do:

   http://api.rubyonrails.com/classes/ActiveRecord/Co...
SchemaStatements.html#M000507

It's really quite a flexible little command.

- Jamis
carl (Guest)
on 2005-11-17 08:28
(Received via mailing list)
Minor nitpick: why does AR:migration make primary keys default to
null?  I always thought that primary keys should never be null.
jamis (Guest)
on 2005-11-17 16:35
(Received via mailing list)
On Nov 16, 2005, at 11:28 PM, Carl Y. wrote:

> Minor nitpick: why does AR:migration make primary keys default to
> null?  I always thought that primary keys should never be null.

Which adapter? I just verified that sqlite and mysql both do NOT NULL
for the primary keys. If there is an adapter doing otherwise, it
probably ought to be submitted as a bug.

- Jamis
carl (Guest)
on 2005-11-17 19:36
(Received via mailing list)
I'm using mysql 4.1.14-nt on Windows with Rails 0.14.3.  The following
migration:

create_table :things do |t|
      t.column :name, :string, :limit => 32, :null => false
end

created a table that looks like this

+-------+-------------+------+-----+---------+----------------+
| Field | Type        | Null | Key | Default | Extra          |
+-------+-------------+------+-----+---------+----------------+
| id    | int(11)     |      | PRI | NULL    | auto_increment |
| name  | varchar(32) |      | UNI |         |                |
+-------+-------------+------+-----+---------+----------------+

I'll look into it further and submit it when I figure out why it's
happening.

Thanks,
Carl
carl (Guest)
on 2005-11-17 19:39
(Received via mailing list)
Sorry I forgot to add that I put a unique index on the table too.  You
may have been wondering why the name column was unique.
jamis (Guest)
on 2005-11-17 19:51
(Received via mailing list)
On Nov 17, 2005, at 10:36 AM, Carl Y. wrote:

> | Field | Type        | Null | Key | Default | Extra          |
> +-------+-------------+------+-----+---------+----------------+
> | id    | int(11)     |      | PRI | NULL    | auto_increment |
> | name  | varchar(32) |      | UNI |         |                |
> +-------+-------------+------+-----+---------+----------------+
>
> I'll look into it further and submit it when I figure out why it's
> happening.

This isn't actually a problem. The important part is what is under
the "Null" column. A blank means that a null value is not allowed in
that column.

- Jamis
carl (Guest)
on 2005-11-17 19:51
(Received via mailing list)
Okay, I get it.  I guess it doesn't matter then, but it would be less
confusing if migrations added a default 0 for all non-null integers.
No big deal though.  THanks.
This topic is locked and can not be replied to.