Changes in a Production Environment

Hi guys, I am planning to make some changes in a Production environment.
This include changes in the model.
I was thinking about making a backup of the database, then running
migrations to zero, making a svn update, running the migrations and then
restoring the database.

Many would ask why I am making a rollback of migrations and then running
them again. It seems that we made some changes to old migrations, so I
prefer doing it this way.

Do you recommend me anything else?

Thanks a lot
Rodrigo

Rodrigo Muiño wrote:

Hi guys, I am planning to make some changes in a Production environment.
This include changes in the model.
I was thinking about making a backup of the database, then running
migrations to zero, making a svn update, running the migrations and then
restoring the database.

Restore, how?

If there are any changes made to the schema then how is your restore
going to handle them?

I analyzed that I wouldn’t have to make data changes to restore the
whole
info. We added some text columns in two tables which have no
restrictions
and created some tables that references another table we already had.

I would backup only data with:
mysqldump -u username -ppassword –no-create-info database_name > *
dump.sql

and restore it with:
mysql -u username -p
password* database_name < *dump.sql

Am I missing anything?

Thanks
Rodrigo

On Tue, Apr 8, 2008 at 3:37 PM, James B. <

Rodrigo Muiño wrote:

I analyzed that I wouldn’t have to make data changes to restore the
whole info. We added some text columns in two tables which have no
restrictions and created some tables that references another table
we already had.

I would backup only data with:
mysqldump -u username -ppassword –no-create-info database_name > *
dump.sql

and restore it with:
mysql -u username -p
password* database_name < *dump.sql

Am I missing anything?

Thanks
Rodrigo

If all you are doing is adding columns to several tables and several
tables and related columns to an existing database then what benefit
does a dump and restore give you? The major benefit of migrations is to
leverage the ALTER TABLE capability of SQL to insert and remove columns
without having to dump and restore.

On 8 Apr 2008, at 22:08, Rodrigo Muiño wrote:

James, Thanks for your answer. We’ll take it into account for the
future.
Now we need to do it the other way because we made changes in older
migrations.
You learn better of your own mistakes.

I think you’d be better off just writing whatever migrations you need
to make your production environment right. For me at least, the
production database (and not the set of migrations and bits that got
you there) is the baseline.

Fred

James, Thanks for your answer. We’ll take it into account for the
future.
Now we need to do it the other way because we made changes in older
migrations.
You learn better of your own mistakes.

Rodrigo

On Tue, Apr 8, 2008 at 5:20 PM, James B. <

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs