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: