Timestamped Migrations Status
As I have reported on the rubyonrails-core mailing list, I have a working solution. Right now, this is a patch against Rails Edge. I am trying to move this code into a plugin, but I have problems with dependencies. I override methods in Rails::Generator::Base, but there is no file named rails/generator/base.rb. That constant is defined in rails_generator/commands.rb, which makes it very hard for the ActiveSupport dependency mechanism to load it.
In the hopes that someone could show me the way, I am making the patch available through the Rails Trac on issue #6838. The patch is timestamped_migrations.v1.patch
What this patch does:
- Generates migrations where the version number is replaced with a UTC timestamp;
- Allows migrating up and down, ordering migrations by name;
- Records which migrations were run in the
schema_migrationstable.
This patch has no tests, but from the command line it seems to work. It even works with the db:sessions:create Rake task.
Enjoy, and either leave comments here or at francois.beausoleil@gmail.com.
2006-12-13 Update: Opened a new ticket as #6838, from #6799.
October 12th, 2007 at 10:25 PM
Do you think timestamps are definitely the way to go? It seems to me that time is not really relevant, only order. But integer migrations cause trouble because you can’t insert in-between migrations or resolve version conflicts. What if we just supported an infinitely divisible version number scheme, instead? Say you have
1_add_user_model.rb<br/> 2_add_join_relationship.rb<br/>Then if we wanted to add an in-between migration, we could just add
1.5_change_user_model.rbOr even, if we don’t need to guarantee order in a certain range
2_change_usr_model.rbwhich would be executed “in parallel” (not really, but in practice; Courtenay had this idea) with the other version 2’s.
What is your use case for timestamps?
October 12th, 2007 at 10:25 PM
Evan, this occurs mostly when branches are created. If a migration is created in a branch, then when the branch is merged back, either you get to do manual conflict resolution (rename the migration), or you use this so the migration runs because the database doesn’t know about it yet.
October 12th, 2007 at 10:25 PM
We are adopting a very similar approach in our multi-branched development – timestamp -based migrations to make them unique, tracking table to make sure we apply only those migrations that have not been used yet. The only difference is that we allow to run migrations even if their timestamp is earlier then the current last migration in a DB. It allows us to just merge from other branches without worrying about renaming of migrations. There is a potential risk of having older migrations overwriting the newest ones, but in reality it is almost non-existent.
BTW, it is being used as a gem. If you want your plugin to override Command, try to put this into your init.rb
require 'rails_generator/base' require 'rails_generator/commands' Rails::Generator::Commands::Base.send(:define_method, :next_migration_number) { Time.now.utc.to_i.to_s }October 12th, 2007 at 10:25 PM
Thank you very much, Val. I’ll try that in a new rev for the patch.