My rails 4 app uses postgis with the activerecord-postgis-adapter. I'm attempting to use Heroku CI. The ci run fails when it is loading the database structure when it reaches a geometry column description in the schema.rb file.
-----> Preparing test database
Running: rake db:schema:load_if_ruby
The PGconn, PGresult, and PGError constants are deprecated, and will be
removed as of version 1.0.
You should use PG::Connection, PG::Result, and PG::Error instead, respectively.
Called from /app/vendor/bundle/ruby/2.5.0/gems/activesupport-4.2.11.1/lib/active_support/dependencies.rb:240:in `load_dependency'
rake aborted!
NoMethodError: undefined method `geometry' for #<ActiveRecord::ConnectionAdapters::PostgreSQL::TableDefinition:0x000055bd614ea1a0>
/app/db/schema.rb:105:in `block (2 levels) in <top (required)>'
/app/vendor/bundle/ruby/2.5.0/gems/activerecord-4.2.11.1/lib/active_record/connection_adapters/abstract/schema_statements.rb:216:in `create_table'
...
My database.yml file specifies the postgis adapter for all environments, so I'm surprised to see it using the postgresql adapter.
Any suggestions?
I previously recorded the database schema in sql. I found a suggestion on the heroku site to switch to ruby. That didn't help.
The tests run fine locally.
I think this is just an issue with HerokuCI. A workaround is to overwrite the DATABASE_URL to specify postgis. Below are two different ways to accomplish that:
Add a .profile file (documented here) in your project root with the following contents:
export DATABASE_URL=`echo $DATABASE_URL | sed s/postgres/postgis/g`
OR Update the test command in your app.json:
{
"environments": {
"test": {
"scripts": {
"test": "export DATABASE_URL=`echo $DATABASE_URL | sed s/postgres/postgis/g`; <other test commands here>",
...
So, for example: if the DATABASE_URL was postgres://foo:bar#example:5432/my-app, that would update it to postgis://foo:bar#example:5432/my-app before any of the relevant commands are invoked.
Related
I enrolled into a web-host plan so I could have my rails apps published. They provided me with a server and access to it. This is a shared CentOS Linux server and I can access its bash.
I was trying to load my database schema into the postgres database (v8.4) they are offering but it gives me an error when doing so.
When I execute:
RAILS_ENV=production rake db:schema:load
The following error is generated:
-- enable_extension("plpgsql")
rake aborted!
ActiveRecord::StatementInvalid: PG::SyntaxError: ERROR: syntax error at or near "EXTENSION"
LINE 1: CREATE EXTENSION IF NOT EXISTS "plpgsql"
^
: CREATE EXTENSION IF NOT EXISTS "plpgsql"
/home/user/path-to-app/db/schema.rb:17:in `block in <top (required)>'
/home/user/path-to-app/db/schema.rb:14:in `<top (required)>'
PG::SyntaxError: ERROR: syntax error at or near "EXTENSION"
LINE 1: CREATE EXTENSION IF NOT EXISTS "plpgsql"
^
/home/user/path-to-app/db/schema.rb:17:in `block in <top (required)>'
/home/user/path-to-app/db/schema.rb:14:in `<top (required)>'
Tasks: TOP => db:schema:load
(See full trace by running task with --trace)
Because the web-host provider does not allow many db privileges, and due to my unfamiliarity with PostgreSQL, I would prefer a solution changing something on the rails side...
Is there something I can do on the rails side to work around (or hopefully address) this issue?
If nothing can be really done from the rails side I would have to be specific with the privileges necessary.
This PostgreSQL EXTENSION object seems to demand privileges my db user does not have...
What would be the minimum privileges for the rails database user running the db migration in PostgeSQL?
Update
This is about PostgreSQL 8.4, witch according to the comments here do not have the "CREATE EXTENSION" command.
CREATE EXTENSION was introduced with Postgres 9.1, i suggest you to run migrations:
RAILS_ENV=production bundle exec rake db:migrate
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
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 need help. When trying to upload my app to heroku, I get this error, anyone know why? A few was wrong. thanks
Using rake (10.1.0)
...
Using tlsmail (0.0.1)
Using uglifier (2.1.2)
Your bundle is complete! It was installed into ./vendor/bundle
-----> Writing config/database.yml to read from DATABASE_URL
-----> Preparing app for Rails asset pipeline
Running: rake assets:precompile
/tmp/build_e8889be5-168c-49ed-81e7-b71061fc82ee/vendor/bundle/ruby/1.9.1/gems/tlsmail-0.0.1/lib/net/smtp.rb:806: warning: already initialized constant SMTPSession
...
/tmp/build_e8889be5-168c-49ed-81e7-b71061fc82ee/vendor/bundle/ruby/1.9.1/gems/tlsmail-0.0.1/lib/net/pop.rb:702: warning: already initialized constant APOPSession
DEPRECATION WARNING: You have Rails 2.3-style plugins in vendor/plugins! Support for these plugins will be removed in Rails 4.0. Move them out and bundle them in your Gemfile, or fold them in to your app as lib/myplugin/* and config/initializers/myplugin.rb. See the release notes for more on this: http://weblog.rubyonrails.org/2012/1/4/rails-3-2-0-rc2-has-been-released. (called from <top (required)> at /tmp/build_e8889be5-168c-49ed-81e7-b71061fc82ee/Rakefile:7)
...
rake aborted!
could not connect to server: Connection refused
Is the server running on host "127.0.0.1" and accepting
TCP/IP connections on port 5432?
/tmp/build_e8889be5-168c-49ed-81e7-b71061fc82ee/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.12/lib/active_record/connection_adapters/postgresql_adapter.rb:1208:in `initialize'
/tmp/build_e8889be5-168c-49ed-81e7-b71061fc82ee/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.12/lib/active_record/connection_adapters/postgresql_adapter.rb:1208:in `new'
...
/tmp/build_e8889be5-168c-49ed-81e7-b71061fc82ee/vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.12/lib/sprockets/assets.rake:29:in `block (2 levels) in <top (required)>'
Tasks: TOP => environment
(See full trace by running task with --trace)
!
! Precompiling assets failed.
From the Heroku docs:
This means that your app is attempting to connect to the database as part of rake assets:precompile. Because the config vars are not present in the environment, we use a placeholder DATABASE_URL to satisfy Rails.
To resolve this issue, ensure that the following line appears in your config/application.rb:
# config/application.rb
config.assets.initialize_on_precompile = false
Once added, commit your change and redeploy to Heroku – your assets should compile without your app attempting to connect to the database, which should resolve the error you're witnessing.
UPDATE:
Line 46 of your stacktrace includes the following message: Devise.secret_key was not set.
According to the author of Devise, José Valim, this issue can be resolved in the following manner:
Please add the following to your Devise initializer:
config.secret_key = '-- secret key --'
Alternatively, the following solution seems to have worked for a number of users:
I went to my routes.rb file and commented out the line devise_for :installs
Then I went back and reran rails generate devise:install. If that doesn't work, use the previous version of devise by editing your Gemfile's reference to Devise like this: gem 'devise', '3.0.3' and then follow the steps i mentioned above.
There a few things that solved this issue for me:
# config/application.rb
config.assets.initialize_on_precompile = false
Then, before I deployed, I compiled my assets locally and committed them:
RAILS_ENV=production bundle exec rake assets:precompile
Also, I installed this heroku add on, as was specified by the app I was launching (in my case, Spree commerce)
heroku labs:enable user-env-compile -a myapp
And of course, make sure your database.yml file is set to use adapter: postgresql.
Commit all of this, push to heroku, and hopefully it will launch. If you still cannot open your app, try looking at the Heroku logs: heroku logs -n 500
I still needed to migrate my database with heroku run rake db:migrate
when you are using github and you are pushing to heroku while you are in develop branch, dont do it, go to master branch and get the updates in the develop by git merge develop
after that,
rails precompile:assets
git add -A
git commit -m "Precompile assets"
git push heroku master
if you want to open the website that you deployed
heroku open
if nothing shows, migrate your database first by:
heroku run rails db:migrate
heroku open
I have failed Heroku proceompiling with same error message.
Carrierwave causes that because I have missed set up SECRET_KEY_BASE to Heroku setting.
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