views:

356

answers:

4

A rails app I am developing currently has about 35 migrations up to this point. Since the application started as an experiment, there is a fair amount of meaningless churn in the migrations as I went back and forth between different ideas.

Are there any drawbacks to collapsing migrations 1-35 into one migration? I was planning to do this by having the first migration load the schema as it is now and deleting all the previous migrations.

I am currently the only person working on this project, if that makes a difference.

+3  A: 

I would keep them around. Don't worry about having to run lots of migrations everytime a new developer checks out the project. He can always run

rake db:schema:load

which is much faster, instead of running

rake db:migrate
erik
+2  A: 

If you have your code under source control (you do have your code under source control, don't you?) then I'd say there's no real harm, provided you accept that rolling back schema changes is going to require either restoration of old migrations or brand new migrations. Just be sure you understand the implications and accept them before setting anything in stone.

Your current schema.rb can form the basis of a new single migration that will start a new set.

Be warned that if you have data manipulation operations in your existing migrations, static data loads, for example, and/or possible subsequent transformations, then these will need to be handled somewhere. It's something I've tripped over a few times...

Mike Woodhouse
A: 

If all your migrations do is modify your table structures I wouldn't worry about it all.

Keep in mind though that some migrations add data - I have ones that seed the database with an admin account and other fixed data - and the schema won't give you this.

Mind you it is a bad idea to do what I do with migrations since I don't use the migrations in deployment. So collapsing migrations might be a good idea for a time to move those data seeding migrations to separate rake tasks.

On review - I am echoing points already made. rake db:migrate VERSION -1

[I blame the distracting new animated logo for drawing my eye away from the text]

srboisvert
+1  A: 

Sometimes migrations may use models that no longer exist or create tables and then later on destroy them, wasting precious CPU time. Best to compile it all into db/schema.rb and get your developers to run rake db:schema:load

Ryan Bigg