I did some local migrations on my own database, and when i tried to migrate on heroku, it was givin me a termination:
Multiple migrations have the name CreateUsers
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.2/lib/active_record/migration.rb:978:in `validate'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.2/lib/active_record/migration.rb:876:in `initialize'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.2/lib/active_record/migration.rb:764:in `new'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.2/lib/active_record/migration.rb:764:in `up'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.2/lib/active_record/migration.rb:742:in `migrate'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.2/lib/active_record/railties/databases.rake:42:in `block (2 levels) in <top (required)>'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)
Ive tried heroku pg:reset DATABASE and migrating again, still gives me this error
Running the database locally seems to be fine. Any suggestions?
This Multiple migrations have the name CreateUsers looks like you have two migrations with the same class name CreateUsers
Please run all of your migrations locally if that are successfully then try to re push in heroku again
hope it will solve your/this problem
I solved this problem this way:
1.check db/migrate folder. You will see at least two files with the same name.
2.delete older files. Use git rm db/migrate/"name of file"
3.push to git
$git add -A
$git commit -m ""
$git checkout master
4.push up to the remote repository and deploy to Heroku:
$ bundle exec rake test
$ git push
$ git push heroku
$ heroku run rake db:migrate
Related
I did the following steps for deploying app and migrating my database:
git add -A
git commit -m "add changes"
git push heroku master
heroku run rake db:migrate
In console I see next:
Running `rake db:migrate` attached to terminal... up, run.9234
== 20150713191218 CreateMovies: migrating =================
-- create_table(:movies)
-> 0.0379s
== 20150713191218 CreateMovies: migrated (0.0381s) ============
heroku restart
But heroku run rake db:migrate does not work. When I run my app, my database is empty. I don't understand why. I don't see any errors.
And I'm sorry, that I repeat this question. I saw that people already asked about this problem, but no advice helped me.
try heroku run rake db:migrate RAILS_ENV=production
To populate your database automatically with rake task you need to use the command RAILS_ENV=production rake db:seed(this will populate your production database) and have a seed file in place. But I guess that was not really what you were looking for
When I run heroku run rake db:migrate, I receive the following error:
$ heroku run rake db:migrate
Running `rake db:migrate` attached to terminal... up, run.8507
rake aborted!
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)
/usr/local/lib/ruby/1.9.1/rake.rb:2367:in `raw_load_rakefile'
/usr/local/lib/ruby/1.9.1/rake.rb:2007:in `block in load_rakefile'
/usr/local/lib/ruby/1.9.1/rake.rb:2058:in `standard_exception_handling'
/usr/local/lib/ruby/1.9.1/rake.rb:2006:in `load_rakefile'
/usr/local/lib/ruby/1.9.1/rake.rb:1991:in `run'
/usr/local/bin/rake:31:in `<main>'
Other users have posted identical errors, but in their case they actually didn't have a Rakefile and it worked for them once they created one, or they were in the wrong directory. My app does have a Rakefile, in the correct directory and with all the proper text in it, and I am in my app's root directory.
This is what my Rakefile looks like:
# Add your own tasks in files placed in lib/tasks ending in .rake,
# for example lib/tasks/capistrano.rake, and they will automatically be available to Rake.
require File.expand_path('../config/application', __FILE__)
Rails.application.load_tasks
This is what "heroku run cat Rakefile" does:
$ heroku run cat Rakefile
Running `cat Rakefile` attached to terminal... up, run.9132
cat: Rakefile: No such file or directory
Whenever you are struggling with Heroku you should check your logs:
heroku logs
Scan through for any errors that you can google and/or get hints to what is going wrong.
If you are using git you can quickly search for errors with this:
git grep "whatever you want to search for"
You will then know where to find the file so you might try to verify that the rakefile actually exists with:
git grep rakefile
Sometimes it is easier to just start fresh and reset your database and reload your current schema with:
rake db:reset db:migrate all
This will destroy your db and then create it and then migrate your current schema:
rake db:drop db:create db:migrate
If you want to reset the heroku db
To drop the database, if you are using SHARED_DATABASE_URL:
heroku pg:reset DATABASE
To recreate the database with nothing in it:
heroku run rake db:migrate
To populate the database with your seed data:
heroku run rake db:seed
I have an app that I have been in happily developing for some time, and haven't had any trouble seeding the production database with my seed file until recently, as I have been attempting to get capistrano deployment working, which spawned an upgrade and gem dependency exercise;-first I blamed capistrano but this behavior happens locally.
So if I reset and seed with:
RAILS_ENV=production rake db:reset
and I end up with tables being undefined that the seed file is attempting to load: e.g:
...tables being built:
.
.
.
-- initialize_schema_migrations_table()
-> 0.0037s
-- assume_migrated_upto_version(20140117153600, ["/Users/jaytho/Projects/1.1.1-a1.dev.merge_test/db/migrate"])
-> 0.0020s
BankCards
rake aborted!
uninitialized constant BankCard
/Users/jaytho/Projects/1.1.1-a1.dev.merge_test/db/seeds.rb:7:in block (2 levels) in <top (required)>'
/Users/jaytho/Projects/1.1.1-a1.dev.merge_test/db/seeds.rb:6:inblock in '
/Users/jaytho/Projects/1.1.1-a1.dev.merge_test/db/seeds.rb:4:in <top (required)>'
/usr/local/rvm/gems/ruby-1.9.3-p448#global/gems/railties-3.2.16/lib/rails/engine.rb:525:inload'
/usr/local/rvm/gems/ruby-1.9.3-p448#global/gems/railties-3.2.16/lib/rails/engine.rb:525:in load_seed'
/usr/local/rvm/gems/ruby-1.9.3-p448#global/gems/activerecord-3.2.16/lib/active_record/railties/databases.rake:347:inblock (2 levels) in '
/usr/local/rvm/gems/ruby-1.9.3-p448#global/gems/activerecord-3.2.16/lib/active_record/railties/databases.rake:290:in `block (2 levels) in '
Tasks: TOP => db:setup => db:seed
(See full trace by running task with –trace)
of which BankCard is the first table seeds.rb is attempting to populate. Comment out BankCard and it just goes to the next table.
The db:reset command works perfectly with in the other environments:
RAILS_ENV=development rake db:reset
and
RAILS_ENV=test rake db:reset
a downgrade to 3.2.15 did not help. I also attempted many permutations like:
bundle exec rake db:reset RAILS_ENV=production
RAILS_ENV=production bundle exec rake db:drop db:create db:migrate db:seed
and I even wiped all my migrations and tried just from the schema thinking that a mangled migration silently causing an issue:
RAILS_ENV=production bundle exec rake db:schema:load db:seed
without any luck- exact same answer.
I also attempted to extract the seed.rb routines into a separate rake task- same result.
The brain twister for me is that if I call the seeds.rb from the console:
'echo load “db/seeds.rb”' | RAILS_ENV=production rails c
she loads without any issues. It works from the console.
I attempted to get into databases.rake and try and recreate the environment there to duplicate the environment into my own rakefile; however, since calls into databases.rake exhibit the same problem, I am pretty much stuck between a rock and a hard place.
What can I be doing wrong to pollute only the production environment? How can I debug this?
Thanks in advance. Beer is on me if you ever are in Dallas.
After some insomnia and some more varied google searches I stumbled on this website: http://community.activestate.com/node/9065 and
Rails 3.2.11 asset precompile fails if threadsafe! enabled where they give clues that threadsafe is important.
Sure enough; if I comment out the threadsafe line in config/environments/production.rb:
# Enable threaded mode
# config.threadsafe!
My rake db:seed tasks work in production.
the solutions in those articles, for some reason didn't work. I ended up doing this to fix it in config/environments/production.rb
# Enable threaded mode
config.threadsafe! unless $rails_rake_task
I hope this helps somebody else out who is upgrading.
I've run pg:reset on Heroku and on trying to run db:migrate, all migrations run but the migration fails with the following error and trace:
rake aborted!
Error dumping database
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0.rc2/lib/active_record/tasks/postgresql_database_tasks.rb:55:in `structure_dump'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0.rc2/lib/active_record/tasks/database_tasks.rb:142:in `structure_dump'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0.rc2/lib/active_record/railties/databases.rake:288:in `block (3 levels) in <top (required)>'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0.rc2/lib/active_record/railties/databases.rake:51:in `block (2 levels) in <top (required)>'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.0.0.rc2/lib/active_record/railties/databases.rake:45:in `block (2 levels) in <top (required)>'
As can be seen here the problematic line and the one above it are:
command = "pg_dump -i -s -x -O -f #{Shellwords.escape(filename)} #{search_path} #{Shellwords.escape(configuration['database'])}"
raise 'Error dumping database' unless Kernel.system(command)
This works locally without any problems, both in development and production environments.
Has anyone experienced anything like this?
This is an interesting bug that, as it turns out, can be ignored. Based on the fact it's attempting to do a db:structure:dump, you are using 'sql' as your active_record.schema_format. The rake task db:structure:dump will fail on heroku because pg_dump is (unsurprisingly) not in the binary path. Interestingly enough, Heroku states that db:schema:dump is not supported but if you set the schema format to ruby, it works fine.
In Rails 3, the dump task would only raise an error is the exit code of the command was 1. On unix based systems if the command is not found, the exit code is 127. So even if the pg_dump command fails on rails 3 (which it does), it won't raise an error and it won't halt the rake task. So anyone using a sql schema format with Rails 3 wouldn't have this issue because it would fail silently. The refactor in Rails 4 to properly raise an error if the dump failed causes db:migrate to raise an error on Heroku. However, even though it errors with rake aborted the ddl is actually performed and committed.
Possible solutions:
Ignore the error as the migrations are actually running.
Since you don't care about the structure dump on production, set the schema_format to ruby. In config/environments/production.rb:
config.active_record.schema_format = :ruby
If for some reason you don't want to change the config file: add a rake task with the following to suppress the error:
if Rails.env == 'production'
Rake::Task["db:structure:dump"].clear
end
The accepted solution is somewhat correct. Heroku does have pg_dump on its runtimes
$ heroku run bash
$ which pg_dump
/usr/bin/pg_dump
The problem comes from this issue: https://github.com/rails/rails/issues/21226 the command cannot be run correctly.
If you need to do a db:structure load instead you can use the $ heroku pg:psql
heroku pg:psql -a your-app-name <db/structure.sql
From heroku rake db:structure:load failure.
If you need to dump you can use this article https://devcenter.heroku.com/articles/heroku-postgres-import-export there's also dedicated commands:
$ heroku pg:pull <REMOTE_SOURCE_DATABASE> <TARGET_DATABASE> # pull from REMOTE_SOURCE_DATABASE to TARGET_DATABASE
$ heroku pg:push <SOURCE_DATABASE> <REMOTE_TARGET_DATABASE> # push from SOURCE_DATABASE to REMOTE_TARGET_DATABASE
If you need to reset your database before running migrations you can use $ heroku pg:reset
I've had an app running on Heroku for a while now and on a recent deployment saw the message that the Heroku gem was deprecated in favor of the Heroku Toolbelt. With the toolbelt, all of my Heroku commands work fine from the command line but within a Rake task (which I have setup for deployments) I get the following errors:
$ rake deploy:staging
Everything up-to-date
/Users/aramisbear/.rvm/gems/ruby-1.9.3-p194#myapp/gems/bundler-1.2.0/lib/bundler/rubygems_integration.rb:147:in `block in replace_gem': heroku is not part of the bundle. Add it to Gemfile. (Gem::LoadError)
from /Users/aramisbear/.rvm/gems/ruby-1.9.3-p194#myapp/bin/heroku:18:in `<main>'
from /Users/aramisbear/.rvm/gems/ruby-1.9.3-p194#myapp/bin/ruby_noexec_wrapper:14:in `eval'
from /Users/aramisbear/.rvm/gems/ruby-1.9.3-p194#myapp/bin/ruby_noexec_wrapper:14:in `<main>'
/Users/aramisbear/.rvm/gems/ruby-1.9.3-p194#myapp/gems/bundler-1.2.0/lib/bundler/rubygems_integration.rb:147:in `block in replace_gem': heroku is not part of the bundle. Add it to Gemfile. (Gem::LoadError)
from /Users/aramisbear/.rvm/gems/ruby-1.9.3-p194#myapp/bin/heroku:18:in `<main>'
from /Users/aramisbear/.rvm/gems/ruby-1.9.3-p194#myapp/bin/ruby_noexec_wrapper:14:in `eval'
from /Users/aramisbear/.rvm/gems/ruby-1.9.3-p194#myapp/bin/ruby_noexec_wrapper:14:in `<main>'
The errors being shown are from this deployment rake task:
namespace :deploy do
desc "deploys to Production after uploading assets to S3"
task :production do
puts `git push heroku master`
puts `heroku run rake db:migrate --app myapp`
puts `heroku restart --app myapp`
end
desc "deploys to Staging after uploading assets to S3"
task :staging do
puts `git push staging staging:master`
puts `heroku run rake db:migrate --app myapp-staging`
puts `heroku restart --app myapp-staging`
end
end
The two heroku commands in each task are where the problem comes from. If I execute them from the command line, they work just fine though. I doubt it matters but I'm running OSX with RVM as well.
Any idea how to fix this? I realize it's not a huge deal since I can just run those additional command manually or alias them, but I'd just like to know why there's a problem in the first place.
The gem's version of the heroku command probably has a higher priority in your PATH than the system's.
I was able to reproduce this in a test project.
When I run which heroku, I see that the shell's choice is /home/justinf/.rvm/gems/ruby-1.9.3-p286/bin/heroku.
All it takes is a simple gem uninstall heroku, answering yes to deleting the executable.
which heroku now gives me /usr/bin/heroku, and my test.rb now completes with no error instead of crashing out with a bundler exception.