migrations based on timestamps

rubyonrails-core
1

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

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 test:units.

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 once?

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

2

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...

??

regards.

-a

3

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

4

Hi,

5

interesting. still, it seems like using

   def next_migration_number      Time.now.utc.iso8601(2)    end

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

would look much nicer than

   def next_migration_number      Time.now.utc.strftime('%Y%m%d%H%M%S').to_i    end

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

in otherwords using an actual timestamp like

   2007-04-14T15:04:28

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:

-a

6

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

Bye !

7

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.

regards.

-a

8

Hi,