Ok, I have stuffed up my migrations. I tried to sort it by deleting duplicates, sorting the schema.rb etc but I don't think I have done it properly.
When I try to deploy to heroku, or rather heroku run rake db:migrate, I get
Multiple migrations have the version number 20130307005437
The migrate works fine on localhost but not heroku.
Unfortunately when I look for migration no 20130307005437, it's not there in my db/migrate.
How can I find it to sort the problem?
While this file might not be visible within your directory listing, I suspect that there might already be a file within your Git repository, which is what is causing this error from appearing on Heroku and not locally.
Please ensure that you've only got one migration inside that Git repo with that number.
Related
Heroku is missing the last 4 migrations for a RoR app. The files exist in the git repository and are named/numbered accordingly. I tried manually forcing that version to run, but it simply can't find it. I tried this:
heroku run rake db:migrate:up VERSION=20190328183515
and the result was
ActiveRecord::UnknownMigrationVersionError: No migration with version number 20190328183515
Trying to redeploy from local to heroku stage does nothing since it states everything is up to date. I tried touching the files in case they weren't included in the deployed files, but looking at the git repository confirmed that's not the case.
Any ideas on what's going on here and how to get heroku to recognize that it is missing 4 migration files that still need to be processed? Resetting the database is not an option. I tried rolling back the database and running the migrations again but it stops on the migration file for 3/27/2019
My understanding is that whoever created the migrations should've also updated schema.rb. Since I've pulled the migrations, I should've also pulled the updated schema.rb. However, once in a while, schema.rb updates after I run bundle exec rake db:migrate.
My current workflow is:
git pull --rebase origin master --prune
rails s
Rails tells me to migrate
bundle exec rake db:migrate
Realize schema.rb updated
At this point, I'm pretty sure I'm not supposed to check in the updated schema.rb. I'd manually revert it through git checkout origin/master db/schema.rb.
So what went wrong in this case? Did a co-worker forget to run migrations after creating them? Did I do something wrong?
As far as I know schema can change after running rails db:migrate because of:
A co-worker did not commit the schema.rb so when you fetched and run the migrations you get the diff
A different DB version is running on your local machine. Based on db configuration schema may be changed accordingly.
Running git diff will help you to understand what is going.
schema.rb retains two key sets of data:
a description of all the tables in your app database structure
a list of all the migrations that have been applied.
if a new developer were to join your team, they should be able to run rake db:schema:load and get an up-to-date database structure straight away. That's far more efficient and reliable than expecting them to run through all the migrations manually.
Running rake db:migrate, even if there are no outstanding migrations that need running, will always regenerate db/schema.rb. Most of the time you won't notice because the file will be the same – but you may get differences in whitespace formatting or column order.
The best practice (IMHO) should always be to check in the updated db/schema.rb in the same commit as any migrations you've added.
When fetching or pulling branches to your local machine, running rake db:migrate will apply whatever new migrations need to be run based on the records in your local database's schema_migrations table. After that, your new db/schema.rb should be the same as the one you pulled down – but if it isn't, git diff will show you what the difference is.
You can then make a judgement call as to what the best course of action is. If the only difference is cosmetic, I personally tend to revert the unstaged changes and leave the committed version untouched until the next migration.
All the above also applies if you have switched to a SQL-based structure file (db/structure.sql) by specifying config.active_record.schema_format = :sql in config/application.rb.
I have some sort of snafu that happened where an intern accidentally uploaded a bit of code to our staging site and then cancelled. Now, there is a page on the staging site that requires a migration that doesn't exist on the staging site.
I'm relatively new to this as well and I'm wondering what the best way to add a migration for that missing column directly to the staging site. Is it
Pull the code, add the migration, push the code (which changes the
staging from the dev, as the dev has the master.
Generate the migration in some other way in heroku directly?
I honestly don't even know if the way we think this error happened is actually the truth. I just have to fix it.
If your migration existed you can rollback on directly on heroku in activity onglet.
or
Pull your repo
Add your migration
Push it on heroku
Run heroku run rake db:migrate --app your_staging_app
Im have this problem many times, i search much and not found any solution to solve, my problem is this:
After the run
git push heroku push master
When i run
heroku run rake db:migrate
i get this error:
Multiple migrations have the version number 20130615132808
im search by this problem and found this:
rails database migration - multiple migrations have the version number x
but when execute git rm appear some options i dont understand much about git so i need solve this problem, in localhost im delete the archives but the problem persists, thanks very much by the help.
Just rename the files with duplicate timestamps (add 1 to the last digit) and then add, commit and push files. When you run heroku run rake db:migrate again all will be dandy.
And for the future remember to not copy and rename migrations by hand (so you don't get repeated version numbers)
This might occur when you copy-paste multiple "rails generate" commands to generate migrations. The migrations generated may have the same time stamp. If you type them in (or copy-paste them) separately, they will have different timestamps.
When this happens, you can simply rename the migration files under db/migrate to contain different timestamps.
I just ran heroku rake db:migrate and three of my most recent migrations are being ignored completely. I've pushed everything to Heroku and github but it's like Heroku doesn't think these even exist.
git status reveals nothing amiss, and my Github repo contains the migration files in the right place.
What's wrong?
Running "heroku restart" from the command line sometimes fixes the issue too.
From what you've said it should work..
If you're completely stuck, you could always try pulling your production database from heroku, migrating on your local machine and then pushing the database back up to heroku?
At the very least you might be able to see what's going on in your database at least?
http://blog.heroku.com/archives/2009/3/18/push_and_pull_databases_to_and_from_heroku/