Migrations and schema.rb - where did I go wrong?

rubyonrails-talk
1

We're a group of 3 developers and eager newcomers to Ruby collaborating on a project.

I started a baseline implementation with a few migrations and models a few weeks ago.

For the first time, we integrated some code... I did the integration... a few models were changed so a few migrations got deleted... and a few models were added, so I copied them over before checking into svn.

Question 1:

Now our migration numbers are not contiguous so we got 001, 003, 006, 007, 008 and 009. Is this emblematic of a problem? Should these always be contiguous?

Question 2:

When I copied the new migrations over (and deleted the others), I ended with a schema.rb was out of date. I had to hand tweak it for db:migrate to work (added blocks for the new models and deleted the old one.

The comments on top of migrate.db read "# This file is autogenerated. Instead of editing this file, please use the # migrations feature of ActiveRecord to incrementally modify your database, and # then regenerate this schema definition."

What did I do wrong that I had to head-tweak schema? How should this integration been done to regenerate the schema? Since we're very early in the development process, we don't have a database to preserve, per se.

Thanks.

2

when you migrate and migration change. You should always do:

rake db:migrate VERSION=0 This will clean out your database.

and then

rake db:migrate This will update your rake to the newest version.

If you have data in your project that you would like to keep after this. Eather make a backup of the date. Or create a fixture, with a .yml fil, with the contense.

I would recormmned, that you renamed your files (migration) , to reflect the the correct order, and so that the order dosn't have any gaps. 001 002 003 003 and so on

Look here http://wiki.rubyonrails.org/rails/pages/UnderstandingMigrations http://wiki.rubyonrails.org/rails/pages/UsingMigrations

you should never change the schema.rb file. Rake reads online in the database the current layout version.

If for some reason you breake the basebase, you can delete all tabled. And that with rake db:migrate

regards svend

3

You may want to check out Automatically — err.the_blog

Whenever I start a project (read not being publically used), using this plugin seems like a good idea. Basically, it allows you to just fool around with the schema.rb and run a rake task and your tables will be automatically adjusted. This is a great way to avoid having a ton of migrations as you experiment with a project early on.

Once the schema have settled down and it is time to deploy for public use, simply load the schema onto the production server (using db:schema:load) and then start using traditional migrations.

4

Nathan Esquenazi wrote:

You may want to check out Automatically — err.the_blog

Whenever I start a project (read not being publically used), using this plugin seems like a good idea. Basically, it allows you to just fool around with the schema.rb and run a rake task and your tables will be automatically adjusted. This is a great way to avoid having a ton of migrations as you experiment with a project early on.

Once the schema have settled down and it is time to deploy for public use, simply load the schema onto the production server (using db:schema:load) and then start using traditional migrations.

Hmm... I use a different approach where periodically, as the number of "niggle" migrations (add a field here, drop a table there) gets above X (largely dependent on how busy I am), I'll rake to VERSION=0, then use the data in the model from annotate_models (great plugin IMHO) to edit the base migration for each model up to current, collapsing the revisions, then just a rake db:migrate to rebuild. Keeps everything consistent, which I like.