I'm developing on my localhost using sqlite and deploying to Postgres on heroku, where the live app is already on heroku.
I've done a lot of development lately which includes several db structure migrations, so I've pulled the Postgres live database to my localhost to run the migrations locally to test (and swapped my local db to Postgres).
When I run rake db:migrate, it tries to run all the migrations from the beginning of time, rather than just the new ones.
How does rake know which migrations to run?
When you migrate first time , then rake will run all the migration .
When you run db:migrate, rails will check a special table in the database which contains the timestamp of the last migration applied to the database. It will then apply all of the migrations with timestamps after that date and update the database table with the timestamp of the last migration. As a result, each migration class is applied exactly once to the database.
source: https://stackoverflow.com/a/6319952/1970061
previously your database was different i.e sqlite, but when you switched to postgres you created new database, hence all table must be created for new database therefore all migration is running
Related
Recently I implemented friendy_id on my rails application. So I generate new column called slug in my existing ActiveRecord model called Category. Everything is working fine. Both my local code and production have same tables and columns. The same code is running on production.
Every now and then I take the mysql database dump from the production server and try to import it to the source code on my local machine. Before I run rake db:migrate I always do rake db:drop and rake db:create.
So After importing the dump I do drop and create and then run rake db:migrate. It fails. Saying Duplicate column slug from categories
So what I've been doing so far is, every time I import dump from production, I am supposed to drop the slug column by doing
ALTER TABLE categories DROP COLUMN slug;
Then When I run rake db:migrate. It runs the last migrations which is created slug for categories. And then the migration ends successfully.
How can I overcome this issue ? I am forced to this every time I want to import the production db to local.
Sounds to me like your schema_migrations tables are no synced between production and development. So rails tries to migrate the last migration (adding slug) which is already added in the database, hence the error.
I am deploying a rails app to nginx.
There are many migrations in the development stage.
How to create the production schema in a simple way instead of reading many migration.rb files ?
Because I deleted several migration files during develepment. Now when deploy production environment it shows me some errors
Thanks
You can use the schema.rb file (via rake db:schema:load), but beware it will drop all existing tables. If you have existing data you will lose it.
Once you load the schema then it sets the database version, so only new migrations that are created after the schema file was created will run in the future.
Here is some info for Rails 4.2 about schema dumping:
Schema Dumping and You
When working on a project, I keep track of all the changes I make to a database in a notepad file. Then, later, I manually write all the changes in rails' db migration file.
But it should be possible to compare the schema of a backup of my database, with the new version of my database, and automatically detect the differences. And generate the rails db migration file automatically.
Is there a tool that can compare two database schema's and automatically generate rails' db migration files?
As far as I'm aware, there's no tool that will do it automatically, however, you can get most of the way there just using rake db:schema:dump with source control.
Create a new Rails project and do the following:
Update database.yml to connect to your first database.
Use rake db:schema:dump to populate schema.rb and commit schema.rb to git.
Update database.yml to connect to your second database and again run rake db:schema:dump
Use git diff on schema.rb to compare the changes. This can easily be mapped to a migration.
The benefit of using source control is that you can then test the migration by comparing schema.rb after the migration runs to the schema dump of the second database.
I'm working on a rails application where we made changes to the schema directly without writing migration files. Now I want load the schema in the development machine to Staging server. But if I did rake db:schema:load, It will erase the data in the database.
Is there anyway to solve this problem? I want to restore the data in the table after running rake db:schema:load.
I have a migration with version number 20120926232105. My schema is at version 20121003190827.
My site is hosted on Heroku, and when I run
heroku run rake db:migrate -a my-app
I get an error that the table it is trying to create in migration 20120926232105 already exists (as it should). I don't get it - isn't the whole point of the schema_migration table to record which was the last successful migration?
This guy explains it pretty well.
Basically, there's a table somewhere called "schema_migrations". Your migration's "version number" is actually just a time stamp. Further, there's no record of a migration with that timestamp in your 'schema_migrations' table. Since the migration exists, and its timestamp wasn't found in the 'schema_migrations' table, Rake knows to run it.
Try grep -r "table_name" db/migrate and see if it's in there twice.