Comments on: Managing Rails migrations http://rc3.org/2006/07/28/managing-rails-migrations/ Strong opinions weakly held Fri, 10 Feb 2012 14:59:55 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Heath Raftery http://rc3.org/2006/07/28/managing-rails-migrations/comment-page-1/#comment-4801 Heath Raftery Sun, 01 Mar 2009 03:03:55 +0000 http://rc3.org/wordpress/?p=7472#comment-4801 <p>Did you ever find a good solution for this? I couldn't find any automated method, so came up with this procedure:</p> <ol> <li>rake db:schema:dump</li> <li>rake db:data:dump (requires yaml_db plugin I believe)</li> <li>script/generate migration create_schema</li> <li>copy contents of db/schema.rb into db/migrate/create_schema, editing as necessary (eg. reorder fields, remove :force option, add t.timestamps, change strings to symbols, create drop_table's for self.down)</li> <li>delete each of the migrations before the newly created one</li> <li>rake db:drop</li> <li>rake db:migrate</li> <li>rake db:data:load</li> </ol> <p>Now the database is up to date and all the migrations have been rolled into one.</p> Did you ever find a good solution for this? I couldn’t find any automated method, so came up with this procedure:

  1. rake db:schema:dump
  2. rake db:data:dump (requires yaml_db plugin I believe)
  3. script/generate migration create_schema
  4. copy contents of db/schema.rb into db/migrate/create_schema, editing as necessary (eg. reorder fields, remove :force option, add t.timestamps, change strings to symbols, create drop_table’s for self.down)
  5. delete each of the migrations before the newly created one
  6. rake db:drop
  7. rake db:migrate
  8. rake db:data:load

Now the database is up to date and all the migrations have been rolled into one.

]]> By: Dave Mathews http://rc3.org/2006/07/28/managing-rails-migrations/comment-page-1/#comment-1052 Dave Mathews Fri, 30 Nov 2007 20:56:50 +0000 http://rc3.org/wordpress/?p=7472#comment-1052 <p>Here is a really, really useful (and pretty!) Rails Migrations cheatsheet in printable PDF format: <a href="http://dizzy.co.uk/articles/rails-migrations" rel="nofollow">Rails Migrations cheatsheet</a></p> Here is a really, really useful (and pretty!) Rails Migrations cheatsheet in printable PDF format: Rails Migrations cheatsheet

]]> By: Rafe http://rc3.org/2006/07/28/managing-rails-migrations/comment-page-1/#comment-1051 Rafe Tue, 01 Aug 2006 04:45:02 +0000 http://rc3.org/wordpress/?p=7472#comment-1051 <p>Actually what I'm talking about is something completely different -- Rails migrations, which let you version schema changes to a database.</p> Actually what I’m talking about is something completely different — Rails migrations, which let you version schema changes to a database.

]]> By: bryan http://rc3.org/2006/07/28/managing-rails-migrations/comment-page-1/#comment-1050 bryan Tue, 01 Aug 2006 03:16:00 +0000 http://rc3.org/wordpress/?p=7472#comment-1050 <p>We typically use branches for items that will break the trunk until they're fully implemented. The rule is the trunk can never break - it must always compile and be functional.</p> <p>Small changes are made to the trunk, but larger changes are branched, and then remerged when complete.</p> <p>If I understand you correctly, Developer A is working on the trunk and B is working on a branch. They both make changes and you want to know how to incorporate them cleanly.</p> <p>When B is ready to move her branch back to the trunk, she first does a refresh from the trunk to ensure that anything new is now in her branch. She tests and verifies that everything works, then merges the branch into the trunk (probably testing a final time).</p> <p>Meanwhile, A is working on the trunk, so just before he commits, he does a refresh; all the new stuff that B added is then added to his local copy. He runs his tests and when they come out clean, he commits.</p> <p>If I recall correctly, if A tries to commit without refreshing, subversion will give a warning that his copy is not up to date and then fail the commit, preventing accedental overwriting of changed objects. I haven't run into this in a long time because my projects for the last few years have consisted of a development team of 1 (me). :P</p> We typically use branches for items that will break the trunk until they’re fully implemented. The rule is the trunk can never break – it must always compile and be functional.

Small changes are made to the trunk, but larger changes are branched, and then remerged when complete.

If I understand you correctly, Developer A is working on the trunk and B is working on a branch. They both make changes and you want to know how to incorporate them cleanly.

When B is ready to move her branch back to the trunk, she first does a refresh from the trunk to ensure that anything new is now in her branch. She tests and verifies that everything works, then merges the branch into the trunk (probably testing a final time).

Meanwhile, A is working on the trunk, so just before he commits, he does a refresh; all the new stuff that B added is then added to his local copy. He runs his tests and when they come out clean, he commits.

If I recall correctly, if A tries to commit without refreshing, subversion will give a warning that his copy is not up to date and then fail the commit, preventing accedental overwriting of changed objects. I haven’t run into this in a long time because my projects for the last few years have consisted of a development team of 1 (me). :P

]]> By: Rafe http://rc3.org/2006/07/28/managing-rails-migrations/comment-page-1/#comment-1049 Rafe Mon, 31 Jul 2006 17:32:23 +0000 http://rc3.org/wordpress/?p=7472#comment-1049 <p>Branching and merging only complicate the problems with migrations. What happens when I make migration #9 in the trunk and you make migration #9 in the development branch? How do we merge the two cleanly?</p> Branching and merging only complicate the problems with migrations. What happens when I make migration #9 in the trunk and you make migration #9 in the development branch? How do we merge the two cleanly?

]]> By: Bryan http://rc3.org/2006/07/28/managing-rails-migrations/comment-page-1/#comment-1048 Bryan Mon, 31 Jul 2006 17:00:44 +0000 http://rc3.org/wordpress/?p=7472#comment-1048 <p>Why not use the suggested subversion branch/tag/trunk directory tree?</p> <pre> \myapp +-\trunk +-\branch | +-\b01 | +-\b02 | +-... +-\tag +-\v-2.1 +-\v-2.3 +-\v-2.5 +-... </pre> <p>So, all main development goes on in the trunk, and the past releases are maintained under their own directories. Any global updates are merged across versions + trunk.</p> <p>See <strong>Branching and Merging</strong> in the <a href="http://svnbook.red-bean.com/" rel="nofollow">subversion book</a> (pp 61-85 in Svn 1.2 rev 2147) for details.</p> Why not use the suggested subversion branch/tag/trunk directory tree?

\myapp
+-\trunk
+-\branch
|   +-\b01
|   +-\b02
|   +-...
+-\tag
+-\v-2.1
+-\v-2.3
+-\v-2.5
+-...

So, all main development goes on in the trunk, and the past releases are maintained under their own directories. Any global updates are merged across versions + trunk.

See Branching and Merging in the subversion book (pp 61-85 in Svn 1.2 rev 2147) for details.

]]> By: paulrobinson.net http://rc3.org/2006/07/28/managing-rails-migrations/comment-page-1/#comment-1053 paulrobinson.net Mon, 31 Jul 2006 03:54:28 +0000 http://rc3.org/wordpress/?p=7472#comment-1053 <p><strong>Rails Migrations Gone Wild</strong></p> <p>Rafe Colburn wonders when you should clean up your Rails migrations: The question becomes, when do you delete all of your migrations and start over with a fresh schema? It seems to me that eventually it comes time to create a fresh database, run all of yo</p> Rails Migrations Gone Wild

Rafe Colburn wonders when you should clean up your Rails migrations: The question becomes, when do you delete all of your migrations and start over with a fresh schema? It seems to me that eventually it comes time to create a fresh database, run all of yo

]]>