NOTE: Using Rails 3.0.7, Postgresql 8.4.4-1, rake 0.8.7.
Trying to get rails testing working.
The command rake db:test:prepare appears to work fine --
$ rake db:test:prepare -t
(in /home/beau/looked)
** Invoke db:test:prepare (first_time)
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:abort_if_pending_migrations
** Execute db:test:prepare
** Invoke db:test:load (first_time)
** Invoke db:test:purge (first_time)
** Invoke environment
** Execute db:test:purge
** Execute db:test:load
** Invoke db:schema:load (first_time)
** Invoke environment
** Execute db:schema:load
NOTICE: CREATE TABLE will create implicit sequence "slugs_id_seq" for serial column "slugs.id"
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "slugs_pkey" for table "slugs"
BUT some of the tables are not being created.
These are the "development" tables:
$ psql -d looked -U admin -c '\d'
List of relations
Schema | Name | Type | Owner
--------+-------------------+----------+-------
public | businesses | table | admin
public | businesses_id_seq | sequence | admin
public | categories | table | admin
public | categories_id_seq | sequence | admin
public | schema_migrations | table | admin
public | slugs | table | admin
public | slugs_id_seq | sequence | admin
(7 rows)
Tables created by rake:db:prepare for the test environment --
$ psql -d looked_test -U admin -c '\d'
List of relations
Schema | Name | Type | Owner
--------+-------------------+----------+-------
public | categories | table | admin
public | schema_migrations | table | admin
public | slugs | table | admin
public | slugs_id_seq | sequence | admin
(4 rows)
As you can see it has created some tables, but not businesses, businesses_id_seq or categories_id_seq.
I'm at a loss as to why, can someone help me?
First make sure to run rake db:migrate before rake db:test:prepare.
If that doesn't work, back up your schema.rb somewhere, remove it, then run rake db:schema:dump before running rake db:test:prepare. That will make sure your schema.rb file fully reflects your database.
Related
Currently, rake db:schema:load is run to setup the database on CircleCI. In migrating from using schema.rb to structure.sql, the command has been updated to: rake db:structure:load.
Unfortunately, it appears to hang and does not return:
$ bin/rake db:structure:load --trace
** Invoke db:structure:load (first_time)
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:structure:load
WARNING: terminal is not fully functional
set_config
------------
(1 row)
(END)rake aborted!
Interrupt:
<STACK TRACE>
bin/rake:9:in `<main>'
Tasks: TOP => db:structure:load
Too long with no output (exceeded 10m0s)
Found someone else with the same issue on CircleCI, no answers though.
This seems to have something to do with the psql client's output to the terminal expecting user input:
set_config
------------
(1 row)
(END) <--- like from a terminal pager
Not exactly a proper solution, but a workaround in .circleci/config.yml:
jobs:
build:
docker:
- image: MY_APP_IMAGE
environment:
PAGER: cat # prevent psql commands using less
Ran into something similar recently on CircleCI with Postgres 11.14.
Here is the thread about it there: https://discuss.circleci.com/t/postgres-failing-with-upgrading-from-11-6-to-11-14/42932/2
Basically needed to add to the Ruby environment section in the Circle CI config.yml:
PSQL_PAGER: ''
Thanks to #swrobel for the fix.
I'm experiencing a really strange issue where rails won't execute migrations on my machine. I'm using Rails 4.2.5, Ruby 2.3.1p112, and Postgres 9.5.3 on OS X 10.11.6.
The database creates/migrates and functions properly at Heroku and on another Mac with the same versions of everything.
If I import the database from Heroku or the other machine I get a pending migration error when running rails s, even when I'm on the same exact source version.
Running a db:schema tells me:
You have 23 pending migrations:
20160627035230 DeviseCreateUsers
20160627035442 CreatePages
20160627055031 AddHeroToPages
20160627061237 AddAdministratorToUser
20160627061943 AddNameToUser
20160628042547 CreateSchools
20160628042702 CreateLicenses
20160628042841 JoinUsersAndSchools
20160628043323 AddJoinCodeToSchools
20160630012028 AddExpiryToLicenses
20160630024743 CreatePurchases
20160630043846 AddOmniauthToUsers
20160704003626 CreateMyIndustries
20160704010403 CreateMyCareers
20160704013913 CreateMyQuestions
20160704074916 AlterMyQuestionsDrop
20160704075947 AlterMyQuestionsChange
20160705071702 CreateUserAttributes
20160710235339 CreateAccessabilities
20160711000000 AddToAccessabilities
20160711044815 CreateMedia
20160711045327 AddLocaleToMedium
20160814010549 CreateInvoices
Run `rake db:migrate` to update your database then try again.
Running the migration then tells me:
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:migrate
ActiveRecord::SchemaMigration Load (0.3ms) SELECT "schema_migrations".* FROM "schema_migrations"
** Invoke db:_dump (first_time)
** Execute db:_dump
** Invoke db:schema:dump (first_time)
** Invoke environment
** Invoke db:load_config
** Execute db:schema:dump
ActiveRecord::SchemaMigration Load (0.2ms) SELECT "schema_migrations".* FROM "schema_migrations"
Listing tables in psql only shows the schema_migrations:
20:09 $ rails db
psql (9.5.3)
Type "help" for help.
mytalents_development=# \dt
List of relations
Schema | Name | Type | Owner
--------+-------------------+-------+----------------
public | schema_migrations | table | aidancornelius
(1 row)
mytalents_development=#
I also seem to get strange errors with db:migrate:up
20:11 $ rake db:migrate:up
rake aborted!
ActiveRecord::UnknownMigrationVersionError:
No migration with version number 0
/usr/local/lib/ruby/gems/2.3.0/gems/activerecord-4.2.5/lib/active_record/migration.rb:939:in `run'
/usr/local/lib/ruby/gems/2.3.0/gems/activerecord-4.2.5/lib/active_record/migration.rb:834:in `run'
/usr/local/lib/ruby/gems/2.3.0/gems/activerecord-4.2.5/lib/active_record/railties/databases.rake:82:in `block (3 levels) in <top (required)>'
/usr/local/lib/ruby/gems/2.3.0/gems/rake-11.2.2/exe/rake:27:in `<top (required)>'
Tasks: TOP => db:migrate:up
(See full trace by running task with --trace)
Does anyone have any insight about what might be going on here? Other projects in Rails 4 and Rails 5 work on this machine, but this one just won't.
Thanks in advance for any suggestions!
I bet this is an issue with Postgres Schemas. I had similar problem, but in my case migrations were working on my local machine and not on Heroku. It was caused by different settings to schema_search_path. On my local machine it was '"$user",public' but '"$user", public'" on Heroku and this additional space was breaking everything.
In your case you need to check what is your schema_search_path on your machine. Maybe you should set it to just "public" in database.yml file. You can check it with SHOW search_path query.
The sequence of rails migration files (and migration process) is the most important part, so you can try to migrate the first migration file using:
rake db:migrate VERSION=20160627035230
then use just db:migrate or db:migrate Version=20160814010549
I have a strange problem with rails migrations.
My db/migrate folder contains migration files and all worked fine.
But a few moment ago, I created a new file using rails g migration MigrationName, it generated a new file. then when i had runned rake db:migrate it rollbacks all and my schema version became 0.
Now when i run rake db:migrate it does nothing whereas db/migrate contains all my migrations.
i tried rake db:reset db:drop db:create db:migrate but no migrations was performed. However it says "migrations are pending run rake db:migrate RAILS_ENV=development" what i've done in vain.
I'm confused. Is anyone ever had this problem?
i've just tried RAILS_ENV=development rake db:migrate --trace and it returns:
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:migrate
** Invoke db:_dump (first_time)
** Execute db:_dump
** Invoke db:schema:dump (first_time)
** Invoke environment
** Invoke db:load_config
** Execute db:schema:dump
Running:
rake db:migrate:status
gives me:
database: database_development
Status Migration ID Migration Name
--------------------------------------------------
up 000 ********** NO FILE **********
down 20150613120151 Devise create users
down 20150613120734 Devise create admins
down 20150614114949 Create gender
down 20150614115642 Create events
down 20150614142610 Create multi events
I tried so many things:
- i dropped my database, restarted postgresql and run again rake db:setup db:migrate. rake db:migrate:status tells me that migrations are pending but it wont migrate.
it makes me crazy...
EDIT
I manually updated schema_migrations in database adding the timestamps
schema:load worked, but when i run rake db:migrate to check if its all good, it rolledback..
EDIT
if i manually fill schema_migrations version in database with timestamps, when i do rake db:schema:status they are all to up and my new migration to down, but if i do rake db:migrate it tries to revert as if i wanted to run rake db:rollback
So i fixed my issue.
In fact, i'm using dotenv to manage environment vars for development, and in my .env file i defined a var called VERSION to describe the API version...
That is the bug !
When i removed it, rake was able to migrate as expected.
I am not sure this will work for, but can you please try the following things,
First, drop tables
rake db:drop
Second, Delete/Remove db/schema.rb file
Third, create database
rake db:create
Fourth, run migration again
rake db:migrate
Please let me know if this help you a bit, good luck :)
I have a new rails app that wil consume from an existing DB (created by another ruby application).
To do so, I created a model for an already existing database table, but now rails gives me the error message that I have to run
rake db:migration
But if I try to do so, I get an error because the table already exists.
Is there any way to perform the migration and ignore existing tables? The table is correct, should be there and is filled with data coming for another application. I would like to have this application to consume the information.
Thanks
Edit:
The DB settings are fine because I was able to perform db:migrations before. I created the model using
rails g model fundo
(fundo is the name of the model and fundoS is the name of the table)
the model has no property yet, but the table has columns
Edit 2:
These are the output if I run with --trace
$ rake db:schema:dump --trace
** Invoke db:schema:dump (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:schema:dump
$ rake db:migrate --trace
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:migrate
== CreateFundos: migrating ===================================================
-- create_table(:fundos) rake aborted! An error has occurred, this and all later migrations canceled: PG::DuplicateTable: ERROR: relation
"fundos" already exists CREATE TABLE "fundos" ("id" serial primary
key, "created_at" timestamp, "updated_at" timestamp)
It seems that rails is trying to recreate the tables. But I just want them to sync because the table is already there!
If you create models for already existing tables using rails g model, just delete the migration file that is created.
The table schema will be dumped correctly in schema.rb, so can always be created from scratch on other machines with rake db:setup, even without the migration file.
You can use rake db:schema:dump to update schema.rb manually.
Are there a lot of migrate file you want to perform? If not too many, you can perform specific version of migrate by
rake db:migrate:redo VERSION=version
If the migrate files to create table not too many, maybe you can edit the migrate file by adding:
if ActiveRecord::Base.connection.table_exists?(table_name)
before create the table.
In your local environment, maybe you could just delete the unnecessary files.
cd db/migrate/
ls | cut -d '_' f1 | while read line; do bundle exec rake db:migrate:up VERSION=$line; done
runs all migrations in file
-- create_table(:fundos) rake aborted! An error has occurred, this and all later >migrations canceled: PG::DuplicateTable: ERROR: relation "fundos" already exists >CREATE TABLE "fundos" ("id" serial primary key, "created_at" timestamp, >"updated_at" timestamp)
What I would do is go to db/migrate and go to that migration file where create_table(:fundos) happens. Comment that line out. Try it again, if it throws an error again, check the error and find the offending code. Then comment it out and keep doing that till it goes thru. Once it goes thru, un-comment everything.
I'm deploying a Rails app that uses PostgreSQL and HSTORE.
To deploy it, I'm ussing rubber.
Everything works, except for HSTORE not being properly enabled. When the migration that contains execute("CREATE EXTENSION hstore") runs, I get the following errors:
** [out :: production.---]
** [out :: production.---] -- execute("CREATE EXTENSION hstore")
** [out :: production.---]
** [out :: production.---] rake aborted!
** [out :: production.---] An error has occurred, this and all later migrations canceled:
** [out :: production.---]
** [out :: production.---] PG::Error: ERROR: permission denied to create extension "hstore"
** [out :: production.---] HINT: Must be superuser to create this extension.
The script that creates the postgres instance has this code:
create_user_cmd = "CREATE USER #{env.db_user} WITH NOSUPERUSER CREATEDB NOCREATEROLE"
so I think the problem might be related to the NOSUPERUSER attribute being set here.
Is there any way to enable hstore using rubber while keeping most of the generated files unchanged?
The problem is that rubber creates the DB user as NOSUPERUSER. My workaround is to create tasks that run before and after capistrano's deploy:migrate that will change the user to SUPERUSER and back.
Here's the code:
namespace :rubber do
namespace :project do
before "deploy:migrate", "rubber:project:add_pg_superuser_and_enable_hstore"
after "deploy:migrate", "rubber:project:remove_pg_superuser"
task :add_pg_superuser_and_enable_hstore,
:roles => [:postgresql_master, :postgresql_slave] do
alter_user_cmd = "ALTER USER #{rubber_env.db_user} SUPERUSER"
create_hstore_cmd = "CREATE EXTENSION IF NOT EXISTS hstore;"
rubber.sudo_script "add_superuser_create_hstore", <<-ENDSCRIPT
sudo -i -u postgres psql -c "#{alter_user_cmd}"
sudo -i -u postgres psql -c "#{create_hstore_cmd}"
ENDSCRIPT
end
task :remove_pg_superuser, :roles => [:postgresql_master,
:postgresql_slave] do
alter_user_cmd = "ALTER USER #{rubber_env.db_user} NOSUPERUSER"
rubber.sudo_script "add_superuser_create_hstore", <<-ENDSCRIPT
sudo -i -u postgres psql -c "#{alter_user_cmd}"
ENDSCRIPT
end
end
end
Another option is to not have a postgres superuser involved when deploying but create a template (or use the default one) and install the extension on the template. Then when you create a database it will have the extension installed.
Good answers here and here.