In my endless stupidness I changed the mysql db using mysql and not migrations, so now the db is out of sync with migration.
my question is, if it's possible to generate the missing migrations (step) and a new schema.db without loosing data and the changes* in the db?
*changes like adding tables, columns.
thx
As far as recreating your migrations, you're out of luck but you can recreate the schema
rake db:schema:dump
If you go this route, when creating a new db (for a new environment etc...) you'll want to do
RAILS_ENV=some_env rake db:schema:load # specify the env if not development
instead of
rake db:migrate
since your migrations do not align with the current schema.
Be careful when running schema:load as it recreates the db from scratch. i.e. you'll lose all data.
It will be good to create the missing migrations. You can fix your local dev database by adding the timestamps to the schema_migrations table manually. That is the consequence of changing your schema by hand.
Also make sure that rake db:migrate:reset (drop all tables and migrate from scratch) will produce the same db/schema.rb as rake db:schema:dump would. Any change in the database schema must be automated by a migration.
The problem with rake db:schema:load is that it will forcefully create the tables.
Related
I have a ruby on rails application already running in production. The database has records which I do not want to loose. I had to add and run new migrations to add some new columns to existing tables. The migrations run successfully and the schema.rb file reflects the changes but the changes do not appear in the database or existing table structure.
Based on research online, rake db:schema:load updates the db based on the schema.rb file. But this resets the database.
It is crucial that I do not loose the data in the tables.Is there any way to solve this? I am fairly new to ruby on rails.
I was able to fix it. I checked the status of migrations in the production environment rake db:migrate:status RAILS_ENV=production and realised they were down. I then run rake db:migrate RAILS_ENV=production and that did it. Changes now reflect in the db. Thanks #muistooshort for the nudge in the right direction
I'm currently following the ruby on rails tutorial: http://guides.rubyonrails.org/getting_started.html.
I am trying to save data into the database. However, when I run: rails server I get the following error:
Migrations are pending. To resolve this issue, run: bin/rake db:migrate RAILS_ENV=development
I've looked at the other articles and when I run:
bin/rake db:migrate
I get a rake aborted!
After running:
rake db:abort_if_pending_migrations....
I see that:
You have 1 pending migration:
20150805200129 CreateDatabases
SQLite3::SQLException: table "databases" already exists:
and it just tells me to run rake db:migrate to start again.
It seems that it already exists. Is there a way to cancel the pending migration?
Sometimes, even dropping a local development database is not a good idea.
There are better ways to delete/destroy a specific migration in your Rails application.
You could use rails d migration command to destroy a particular migration:
rails d migration MigrationName
To undo the changes corresponding to a particular migration, you can use db:migrate:down method like this:
rake db:migrate:down VERSION=XXX
Sometimes, things could get more messy and in those situation another handy thing is to take a look at the schema_migrations table in your database which has all the migrations with their version saved in it.
You can delete a particular migration from this table like this:
delete from schema_migrations WHERE version = VERSION;
if you don't want that migration to be present anymore.
Your migration may have failed midway (so it created the table, but didn't finish).
You are just using development environment, so it's okay to just drop the database and rebuild it from scratch:
rake db:drop # THIS WILL DELETE YOUR DATABASE
rake db:create
rake db:migrate
If you are like me and maintain your database structure outside of Rails, you can just delete the migration file from db/migration. I got the error in the OP's question when I used the rails generate command to create a model class, forgetting that it also creates a migration file.
Do not use this method if you rely on Rails to maintain your database structure!
I keep my Rails structure file up to date by building it from the database using:
bundle exec rake db:structure:dump
I do not encourage to drop the database and start from the beginning especially when you already have the data inside the database.
My approach to this will be migrate first, then rollback. After that you can safely delete the migration file. So the procedure is as following.
rails db:migrate
rails db rollback
rm db/migrate/your_last_migration_file.rb
You can recreate database and run all migrations in your development environment with such command
rails db:migrate:reset
If you want to revert the wrong migrations, You can drop the whole db using this:
rake db:drop
Then remove the migrations file manually(This wont corrupt the db when you recreate as the Schema migrations would be dropped as well).
Then run
rake db:migrate
And if there is data to be seeded, then run this as well
rake db:setup
Getting a migration error when I try to migrate my database on Heroku. Found a solution on here offering this advice:
rake db:create
rake db:schema:load
rake db:migrate
but it hasn't made a difference. The error starts like this:
PG::UndefinedColumn: ERROR: column "property_id" of relation "bookings" does not exist
I don't have a property_id column anymore as this got changed in later migrations locally.
My migrations work locally by the way so why not on Heroku?
Could you post your Schema so I can see if you have a column "property_id".
If you do not then you will have to add this column property_id to the bookings class.
Also try
rake db:drop
rake db:migrate
what happens?
Did you migrate data to or from your heroku postgres database and your local one? It seems like the schema_migrations table is out of sync with reality on your heroku instance.
If you can lose all data, I would just start over. The following command will wipe your entire database, destroy all tables:
heroku pg:reset # destructive action, careful
After that, try heroku run rake db:migrate again; it should work.
If that does not work, then you'll probably have to manually inspect the schema_migrations table and make sure that the correct migrations have been applied and perhaps manually put it back in a consistent state.
This situation is quite abnormal and can only have happened by manually touching this data or schema. Because postgres supports transactional DDL, it cannot have happened via heroku run rake db:migrate alone, as in case of errors the whole migration rolls back and the database is left in a consistent state.
I have been mucking with my development database and am getting ready to move it to production. I made some edits outside of rails, so I don't have a migration for all of my changes. I know I can rake db:schema:dump to generate a schema.rb file, but can I apply that to an already populated production db without wiping the data? Something similar to rake db:schema:load without wiping the data?
If not, do I just need to manually create the migrations that would catch the production db up? If I do make those migrations, won't all future calls to rake db:migrate on the dev box fail because the change in the migration already exists in the dev db?
The problem with rake db:schema:load is that it will forcefully create the tables, which you can see in db/schema.rb:
create_table :users, :force => true do |t|
# etc
end
What I would recommend is that you do create the missing migrations. You can fix your local dev database by adding the timestamps to the schema_migrations table manually. That is the consequence of changing your schema by hand.
I personally always make sure that rake db:migrate:reset (drop all tables and migrate from scratch) will produce the same db/schema.rb as rake db:schema:dump would. Any change in the database schema must be automated by a migration. You could even make it part of your CI script, by running rake db:migrate:reset and than asserting that db/schema.rb didn't change from what is in source control.
Due to some deployment issues I stopped tracking schema.rb in git. Somehow I have stuffed this up and somewhere along the way my schema.rb file has disappeared.
Is there a way of regenerating schema.rb from the database or from the migrations? I would prefer not to lose the existing data.
If you run a rake -T it will list all possible rake tasks for your Rails project. One of them is db:schema:dump which will recreate the schema.rb for the Rails app from the database.
bundle exec rake db:schema:dump
Careful,
rake db:schema:dump
will dump the current DB schema FROM the DB. This means that if you made any changes to your migrations, they will NOT be reflected in schema.rb file which is not what you want IMO.
If you want to re-create the schema from the migrations, do the following:
rake db:drop # ERASES THE DATABASE !!!!
rake db:create
rake db:migrate
RAILS 5 Way:
rails db:schema:dump
or if you Encounter Gem::LoadError then:
bundle exec rails db:schema:dump
Note:
in rails 5 it is recommended that task are generated/executed by using rails instead of rake, this is just to remember, rails generated task are of extension .rake see in lib/tasks/myTask.rake. which means these task can also be executed by prepending rake.
rake db:schema:dump
I think this is still valid in Rails 3 - it regenerates the schema.rb from the database.
Directly from the schema.rb file itself:
If you need to create the application database on another
system, you should be using db:schema:load, not running all the migrations
from scratch. The latter is a flawed and unsustainable approach (the more migrations
you'll amass, the slower it'll run and the greater likelihood for issues).
So do NOT do the suggestion of rake db:migrate, which was suggested in the - at the time of this writing - lowest rated answer.
If you regenerate schema.rb locally, you should be alright. It simply holds a representation of the structure of your database tables. The data itself is not contained in this file.
To regenerate your schema.rb file, run:
bundle exec rake db:schema:dump
Then simply commit the new schema.rb file and you should be in good shape!
I also had a similar problem where my old schema was not refreshing even if I deleted migration.
So, what I did was dropping all existing tables in the database and migrating them again. Then running "db:schema:load" command gave me a fresh schema.rb.
drop table my_table_name // deleted them individually
rake db:migrate
rake db:schema:dump // re-created a new schema