I’m having some problems with migrations (on rails 1.2.x). I suppose
it is not a rare problem, but my google-foo didn’t help me this time.
Briefly, my problem is that when modifying some models I may (and tend
to) do backward-incompatible changes. Method deletion, or signature
changing, for instance. Now, if a past migration used the “old API”,
it will surely break when someone do a full migration. I suppose that
this could be solved by modifying old migrations, but (a) I have a gut
feeling against modifying migrations and (b) it won’t work when your
backward-incompatible change has something to do with a change of the
database structure, because, when running the old migration the new
structure has not been migrated yet.
Let’s put it with a minimal example. I have this model:
class Foo < ActiveRecord::Base
end
class AddAnotherFieldToFoo < ActiveRecord::Migration
def self.up
add_column :foo, :new_column, :string
Foo.reset_column_information
Foo.find(:all).each do |foo|
foo.new_column = some_calculation(foo.another_column)
foo.save!
end
end
end
And later I change the Foo model:
class Foo < ActiveRecord::Base
has_many :bars
before_save :do_something_with_my_bars
def do_something_with_my_bars
…
end
end
And now I have just broke the AddAnotherFieldToFoo migration. This
affects new developers (who will start doing a checkout and a full
migration to get a up-to-date database), existing developers who
hasn’t updated they working copy between the two events, and
deployments intro production (as long as they include two incompatible
events as shown on my example).
AFAICS, this is a problem of “keeping in sync” the state of models and
migrations over the time. How do you solve this? Or am I using
migrations in a way they were not intended to be used?
Any ideas and/or observations are welcome!
Thanks,
–
Leo Soto M.
http://blog.leosoto.com