Rails - Jul 2008 - How to maintain migrations?

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!

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

On Tue, Jul 15, 2008 at 04:39:29PM -0600, Sean Clark 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


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

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.

On Jul 15, 5:39 pm, "Sean Clark Hess"
<seanh...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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!
--~--~---------~--~----~------------~-------~--~----~
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@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Great, thanks for the advice guys.

On Wed, Jul 16, 2008 at 4:38 AM,
ixquic696969-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org <
ixquic696969-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> 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.
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---