# How to maintain migrations? **URL:** \ **Category:** Rails\ **Created:** [July 16, 2008, 12:39am UTC](https://www.ruby-forum.com/t/how-to-maintain-migrations/143174 "2008-07-16T00:39:56Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Sean\_CSHess](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/94ad74/32.png) [@Sean\_CSHess](https://www.ruby-forum.com/u/Sean_CSHess)\ **Post date:** [July 16, 2008, 12:39am UTC](https://www.ruby-forum.com/t/how-to-maintain-migrations/143174/1 "2008-07-16T00:39:56Z")
Hi everybody, I’m trying to figure out the best way to do migrations. I’m sure it’s a personal preference in some ways, but how do you prefer to maintain migrations? Do you create a new migration every time you think of a change, or do you change the existing ones, then rake db:migrate to 0 and back again? If you do the first, you don’t have to be constantly recreating your tables, but your table code is all over the place. What do you all prefer? Thanks! ---
**Author:** ![Sean\_CSHess](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/94ad74/32.png) [@Sean\_CSHess](https://www.ruby-forum.com/u/Sean_CSHess)\ **Post date:** [July 16, 2008, 3:31am UTC](https://www.ruby-forum.com/t/how-to-maintain-migrations/143174/2 "2008-07-16T03:31:56Z")
During early development when I’m changing things drastically I’ll update my initial migrations and rake back to 0 each time. After my tables are all somewhat finalized, then I create a new migration for each change. ---
**Author:** ![Sean\_CSHess](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/94ad74/32.png) [@Sean\_CSHess](https://www.ruby-forum.com/u/Sean_CSHess)\ **Post date:** [July 16, 2008, 3:34am UTC](https://www.ruby-forum.com/t/how-to-maintain-migrations/143174/3 "2008-07-16T03:34:52Z")
On Tue, Jul 15, 2008 at 04:39:29PM -0600, Sean C. Hess wrote: > Hi everybody, I’m trying to figure out the best way to do migrations. > I’m sure it’s a personal preference in some ways, but how do you prefer > to maintain migrations? > Do you create a new migration every time you think of a change, or do you > change the existing ones, then rake db:migrate to 0 and back again? > > If you do the first, you don’t have to be constantly recreating your > tables, but your table code is all over the place. What do you all > prefer? Thanks! If you’re working alone, you can often afford to be sloppy. Better, though, is to be rigorous as if you were working with other people all the time. That means a migration for every change. When you actually release something (which usually involves tagging in subversion or whatever SCM you use) you can do a rake db:schema:dump to get a db/schema.rb file then wipe out your migrations and replace them with the contents of the schema.rb (as a migration with the next version number). Of course, if any of your migrations were doing straight SQL you may need to do some tweaking by hand. –Greg ---
**Author:** ![Sean\_CSHess](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/94ad74/32.png) [@Sean\_CSHess](https://www.ruby-forum.com/u/Sean_CSHess)\ **Post date:** [July 16, 2008, 2:04pm UTC](https://www.ruby-forum.com/t/how-to-maintain-migrations/143174/4 "2008-07-16T14:04:23Z")
Great, thanks for the advice guys. On Wed, Jul 16, 2008 at 4:38 AM, removed\_email\_address@domain.invalid \< ---
**Author:** ![Sean\_CSHess](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/94ad74/32.png) [@Sean\_CSHess](https://www.ruby-forum.com/u/Sean_CSHess)\ **Post date:** [July 16, 2008, 1:04pm UTC](https://www.ruby-forum.com/t/how-to-maintain-migrations/143174/5 "2008-07-16T13:04:11Z")
The orthodox view is that migrations should reflect every previous state of your database structure, so if an old version of your app is deployed somewhere you can painlessly migrate it from there. Fiddling with old migrations is also tricky because migrating back up can fail (e.g. if you forgot to include something you did by hand, initializations…). But if the old migrations were just private (not deployed anywhere) and some of them are nothing but confusing (dead ends, mistakes) I sometimes gloss them over, because looking at migrations can be a good way to learn what tables and fields are at the core of the app. Very old migrations from a stage where the app wasn’t functional yet can be reduced to a schema.rb as Gregory said, and it’s a good thing to do. When I realize that I want to change something that logically belongs in a very recent migration, I migrate up, edit the migration and migrate back to the last version. That’s relatively safe to do and helps to keep an overview.