SQLite3 put a parse error in my schema.rb for timestamps

Railsers:

I switched from MySQL to Sqlite3 for Test-Driven Development. It meant
the difference between

(Long term, I want to understand the db:migrate system well enough
that I can run a long test, occassionally, that migrates everything to
MySQL and retests it there. That will prevent nasty surprises at
deployment time. But that’s not the current question!)

Because I don’t lean on db:migrate yet, I start the cycle by keeping a
file, db/create.sql, and if it upgrades, then my tests run it in the
database to create the schema. So the table contains goodies like
these:

drop table chats;

create table chats (
id integer primary key, – auto_increment,
user_id integer not null,
panel_id integer not null,
uttered_at timestamp DEFAULT CURRENT_TIMESTAMP,
utterance varchar(255) not null
);

(Note, for example, that MySQL will [sometimes] require the
auto_increment, but SQLite can’t use it.)

Now note the timestamp DEFAULT CURRENT_TIMESTAMP. That’s because I’m
too lazy to write Time.now inside the model code for the Chat object.
I want the database itself to take care of low-level details.

But something is migrating that schema back into schema.rb looking like
this:

create_table “chats”, :force => true do |t|
t.column “user_id”, :integer, :null => false
t.column “panel_id”, :integer, :null => false
t.column “uttered_at”, :timestamp, :default => Fri Nov 17 18:03:40
-0800 2006
t.column “utterance”, :string, :null => false
end

Notice :default => points to a timestamp that’s A> not in :db format,
and B> isn’t a string. This causes a big cascade of silly syntax
errors.

What is Rails (or, possibly, me) doing wrong?


Phlip
http://c2.com/cgi/wiki?ZeekLand ← NOT a blog!!

I switched from MySQL to Sqlite3 for Test-Driven Development. It meant
the difference between

2 minutes and 8 seconds for a short batch of lean functional tests.