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

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.

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

regards
svend

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

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.

Nathan E. 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.