
Serial doesn't work correctly using migrations and SQLite3
Reported by Mark Bates | August 4th, 2008 @ 12:57 PM
If using migrations w/ SQLite3 the Serial data type doesn't create an auto-incrementing column.
Here's my code:
require 'rubygems'
require 'dm-core'
require 'dm-migrations'
require 'migration_runner'
include DataMapper::Types
DataMapper.logger = DataMapper::Logger.new(STDOUT, :debug)
DataMapper.setup(:default, "sqlite3:///foo.db")
class User
include DataMapper::Resource
property :id, Serial
end
# User.auto_migrate!
migration 1, :create_user do
up do
create_table :users do
column :id, Serial
end
end
end
migrate_up!
It generates the following output:
Mon, 04 Aug 2008 17:53:32 GMT ~ debug ~ PRAGMA table_info('migration_info')
== Performing Up Migration #1: create_user
CREATE TABLE "users" ("id" INTEGER NOT NULL DEFAULT NULL)
Mon, 04 Aug 2008 17:53:32 GMT ~ debug ~ CREATE TABLE "users" ("id" INTEGER NOT NULL DEFAULT NULL)
-> 0.0018s
-> 0.0021s
Mon, 04 Aug 2008 17:53:32 GMT ~ debug ~ PRAGMA table_info('migration_info')
Mon, 04 Aug 2008 17:53:32 GMT ~ debug ~ CREATE TABLE "migration_info" ("migration_name" VARCHAR(255) UNIQUE)
Mon, 04 Aug 2008 17:53:32 GMT ~ debug ~ INSERT INTO "migration_info" ("migration_name") VALUES ('create_user')
If I were to run this using auto_migrate! I get the following:
Mon, 04 Aug 2008 17:56:28 GMT ~ debug ~ CREATE TABLE "users" ("id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT)
Which is correct.
Comments and changes to this ticket
-
Jonathan Stott (namelessjon) November 30th, 2008 @ 09:08 AM
- Milestone cleared.
- State changed from new to open
- Assigned user cleared.
-
Paul Sadauskas (Rando) December 8th, 2008 @ 03:47 PM
- Assigned user set to Paul Sadauskas (Rando)
- State changed from open to unconfirmed
-
Paul Sadauskas (Rando) December 12th, 2008 @ 04:02 PM
- State changed from unconfirmed to accepted
-
Dan Kubb (dkubb) December 14th, 2008 @ 03:11 AM
Actually, in SQLite3, if you have an integer PK, it will automatically be auto-incrementing:
http://www.sqlite.org/faq.html#q1
However, even though inserting into a table like this is faster than an explicit AUTOINCREMENT, the downside is that it can re-use previously deleted keys, which for me is a deal breaker.
-
Piotr Solnica (solnic) March 24th, 2011 @ 07:16 AM
- State changed from accepted to resolved
- Milestone order changed from 0 to 0
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »