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
On Nov 16, 2005, at 1:31 PM, Carl Youngblood 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
Great, thanks for the help! On 11/16/05, Jamis Buck <jamis-uHoyYlH2B+GakBO8gow8eQ@public.gmane.org> wrote:> On Nov 16, 2005, at 1:31 PM, Carl Youngblood 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
On Nov 16, 2005, at 2:00 PM, Carl Youngblood 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/ConnectionAdapters/ SchemaStatements.html#M000507 It''s really quite a flexible little command. - Jamis> > On 11/16/05, Jamis Buck <jamis-uHoyYlH2B+GakBO8gow8eQ@public.gmane.org> wrote: >> On Nov 16, 2005, at 1:31 PM, Carl Youngblood 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 > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Minor nitpick: why does AR:migration make primary keys default to null? I always thought that primary keys should never be null.
On Nov 16, 2005, at 11:28 PM, Carl Youngblood 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
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
On 11/17/05, Jamis Buck <jamis-uHoyYlH2B+GakBO8gow8eQ@public.gmane.org>
wrote:> On Nov 16, 2005, at 11:28 PM, Carl Youngblood 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
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
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. On 11/17/05, Carl Youngblood <carl-MJzSGySFh6ZUfOvSQQQpYw@public.gmane.org> wrote:> 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 | | | > +-------+-------------+------+-----+---------+----------------+
On Nov 17, 2005, at 10:36 AM, Carl Youngblood wrote:> 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.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
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. On 11/17/05, Jamis Buck <jamis-uHoyYlH2B+GakBO8gow8eQ@public.gmane.org> wrote:> 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.