migrations based on timestamps

I have been [trying] to use migrations with UNIX timestamps, so
multiple developers can add migrations without tipping on each others

And hence I tried this:

It works, at least rake db:migrate. but other rake commands that deal
with database is broken and hence rake db:test:prepare or rake

I ran above commands with --trace enabled and I found some curious things:

gnufied@xaos:~/simple_markets$ rake db:migrate --trace
/usr/local/bin/rake:17:Warning: require_gem is obsolete. Use gem instead.
(in /home/gnufied/simple_markets)
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
"Hello World" #=> init.rb of enhanced
migrations plugin called.
** Execute db:migrate
== Alerts: migrating ==========================================================
-- create_table(:alerts)
   -> 0.0629s
== Alerts: migrated (0.0632s) =================================================

== Devices: migrating =========================================================
-- create_table(:devices)
   -> 0.0095s
== Devices: migrated (0.0100s) ================================================

** Invoke db:schema:dump (first_time)
** Invoke environment
** Execute db:schema:dump

Now, lets see the flow when I run rake db:test:prepare:

gnufied@xaos:~/simple_markets$ rake db:test:prepare --trace
/usr/local/bin/rake:17:Warning: require_gem is obsolete. Use gem instead.
(in /home/gnufied/simple_markets)
** Invoke db:test:prepare (first_time)
** Invoke environment (first_time)
** Execute environment
"Hello World"
** Execute db:test:prepare
** Invoke db:test:clone (first_time)
** Invoke db:schema:dump (first_time)
** Invoke environment
** Execute db:schema:dump
** Invoke db:test:purge (first_time)
** Invoke environment
** Execute db:test:purge
** Execute db:test:clone
** Invoke db:schema:load (first_time)
** Invoke environment
** Execute db:schema:load
rake aborted!
Mysql::Error: Table 'simple_markets_test.schema_info' doesn't exist:
SHOW FIELDS FROM schema_info
** All Hell broke loose here.

So, in a nutshell, enhanced migrations plugin has deleted schema_info
table and uses migrations_info table. But above trace makes me wonder,
why db:test:clone and couple of other tasks are being invoked more the

I don't have a definite solution to the problem, and so i ask.

why not simply add an iso8601 timestamp to the migration name? that way the
semantics of timestamps can be gained simply be encoding the name with it
rather than some random number. iso8601 has the nice property that the string
sort is the same as the time ordering...




Hmm nice idea, would make them more readable.
Anyway the problem I asked is fixed now, some patches back and forth.


interesting. still, it seems like using

   def next_migration_number

   def next_migration_string(padding = :ignored)
     "%.s" % next_migration_number

would look much nicer than

   def next_migration_number

   def next_migration_string(padding = 14)
     "%.#{padding}d" % next_migration_number

in otherwords using an actual timestamp like


in the migration name for the benefit of developers that don't tranlate
seconds since 1970 in their heads - although this change would definitely be
more extensive...

then again - you've already done the work :wink:


Yes, but the file's ctime essentially gives us the same information,
plus or minus a few seconds.

Bye !

not really. ctime is updated by chmod, chown, or even making links. i
certainly wouldn't want my db state determined by this time stamp. there
really isn't a concept of 'creation time' in unix. ctime is 'change time'.

the beauty of using timestamps in the pathname (in utc) is that multiple
developers on multiple machines can create migrations on whatever filesystem
(windows, mac, etc) they choose: do a check in - and everything will work
itself out.