AR::migration - how to change the primary key

Rails
1

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

2

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
3

Great, thanks for the help!

4

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

5

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:

Peak Obsession
SchemaStatements.html#M000507

It’s really quite a flexible little command.

  • Jamis
6

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

7

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.

8

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
9

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
10

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.