URGENT + production migrations

Champs,

I am in a great need of you people. My migrations are not running on production database. I done some changes in production mode and then i ran rake db:migrate RAILS_ENV=production / RAILS_ENV="production". But my database is not reflecting. Can you people tell me that what are the possible combinations of mistake i am doing .. :slight_smile:

I am in a great need of you people. My migrations are not running on production database. I done some changes in production mode and then i ran rake db:migrate RAILS_ENV=production / RAILS_ENV="production". But my database is not reflecting. Can you people tell me that what are the possible combinations of mistake i am doing .. :slight_smile:

Have you changed database configuration in your database.yml?

Are you getting any error messages (command line or in the log)?

Did you create new migrations or edit existing ones?

Does the list of applied migrations (select * FROM schema_migrations;) match the list of migrations you expect to have been run (excluding the new ones you're thinking should run)?

Does "script/console production" work and give you access to your production system?

Are you using a SQLite production database (I don't know how big your site is) that is then being removed and symlinked from a shared DB by Capistrano after migration?

Running out of ideas until I get some answers...

Cheers,

Andy

Andy Jeffries wrote:

Have you changed database configuration in your database.yml?

No. I have'nt changed.

Are you getting any error messages (command line or in the log)?

No i am not getting any error message at command line/log file.

Did you create new migrations or edit existing ones?

I edited migrations on my local machine and checked in them.. :slight_smile: Just now i realised that this could be the problem of me.

Ok tell me one thing, if i edit a already migration file, and run rake db:migrate then would that column be get affected.. ?

Does the list of applied migrations (select * FROM schema_migrations;) match the list of migrations you expect to have been run (excluding the new ones you're thinking should run)?

Did not checked this.

Does "script/console production" work and give you access to your production system?

Yeah.

Are you using a SQLite production database (I don't know how big your site is) that is then being removed and symlinked from a shared DB by Capistrano after migration?

I am using MySql.

No. rails stores which migrations have been run - if you edit it after it's been run rails won't run it again.

Fred

Did you create new migrations or edit existing ones?

I edited migrations on my local machine and checked in them.. :slight_smile: Just now i realised that this could be the problem of me.

It is indeed :slight_smile:

Ok tell me one thing, if i edit a already migration file, and run rake db:migrate then would that column be get affected.. ?

Nope. The schema_migrations table in your database holds a list of ids that have already been applied, so editing existing migrations that have already been applied will not apply them again.

You need to create a new migration and put all your changes in there.

Cheers,

Andy

Andy Jeffries wrote:

Did you create new migrations or edit existing ones?

I edited migrations on my local machine and checked in them.. :slight_smile: Just now i realised that this could be the problem of me.

It is indeed :slight_smile:

Resolved it. Thanks to all of you with a big smile .. :slight_smile: :slight_smile:

I edited migrations on my local machine and checked in them.. :slight_smile: Just now i realised that this could be the problem of me.

It is indeed :slight_smile:

Resolved it. Thanks to all of you with a big smile .. :slight_smile: :slight_smile:

Happy to help.

Good luck,

Cheers,

Andy

I know this has already been resloved, but instead of creating a new migration, you could have gone back to version 0

rake db:migrate VERSION=0

then run rake db:migrate

this should update all migrations you edited.

The downside is that migrations will often have a create_table in the up method and a drop_table in the down method. As Hemant said this was on a production system, doing as you suggest would lose all his live/production data.

Probably not the solution he'd desire :slight_smile:

Cheers,

Andy

The downside is that migrations will often have a create_table in the up method and a drop_table in the down method. As Hemant said this was on a production system, doing as you suggest would lose all his live/production data.

Probably not the solution he'd desire :slight_smile:

Point taken :slight_smile: