Rails - Mar 2008 - 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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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

On Mar 20, 5:50 am, nahabed
<roup...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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 received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

You may want to check out http://errtheblog.com/posts/65-automatically

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.
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Nathan Esquenazi wrote:
> You may want to check out http://errtheblog.com/posts/65-automatically
> 
> 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.
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---