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
Related
I'm trying to get some code running locally. But am running up against a problem when I run:
rake db:create db:migrate db:seed --trace
Using Postgres.
We have the gem scenic included which creates database views using create_view but for some reason when the migration reaches the migration file which creates a view I get the following error:
steve-vmn:ss steve$ rake db:create db:migrate db:seed --trace
RAILS_GROUPS is unset; defaulting to web,worker
** Invoke db:create (first_time)
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:create
Database '22_development' already exists
Database '22_test' already exists
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config
** Execute db:migrate
== 20170816124642 CreateStations: migrating ======================
-- create_view(:stations)
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
No such file or directory # rb_sysopen - /Users/steve/Ss/ss/db/views/stations_v01.sql
/Users/steve/.rvm/gems/ruby-2.4.1/gems/scenic-1.5.1/lib/scenic/definition.rb:10:in `read'
/Users/steve/.rvm/gems/ruby-2.4.1/gems/scenic-1.5.1/lib/scenic/definition.rb:10:in `to_sql'
Rake file:
class CreateStations < ActiveRecord::Migration[5.0]
def change
create_view :stations
end
end
I can't seem to find a similar error anywhere.
Based on the error message, and the scenic documentation, you need to define a SQL view in db/views/stations_v01.sql. See the following link for an example.
https://github.com/scenic-views/scenic#great-how-do-i-create-a-view
See docs: https://github.com/scenic-views/scenic/blob/master/README.md
As mentioned in your error logs, there is no file exists: db/views/stations_v01.sql that comes after running the migration.
rails generate scenic:view stations
create db/views/stations_v01.sql
create db/migrate/[TIMESTAMP]_create_stations.rb
After that
Edit the db/views/stations_v01.sql file with the SQL statement that defines your view.
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 running a (previously working fine) seed file like so:
I check to see if there are pending migrations with rake db:migrate:status and all migrations are "up".
For additional context, here's what led me to this point:
Working in 6 year old Rails Code
Start a branch for feature "A"
Wrap feature "A". Checkout new branch for Feature "B"
Master --> "A" --> "B"
Finish feature "B" + commit
Checkout "A" for refactoring
Add column to migration for "A" (nothings been merged with master yet, so I figure I can drop and rebuild my dev db no problem WRONG)
Wrap refactoring for "A" + Commit
Checkout Branch "B"
9 Merge "A" into "B"
Drop DB
Create DB with bin/rake db:create db:schema:load All good
Run rake db:seed and nothing happens.
Run with trace and get the error you see above.
Have no idea what's causing this.
More Context
-Ruby 2.3.1
-Rails 4.2.7.1
-Postgresql 9.6.2
It doesn't look like you actually have a problem; abort_if_pending_migrations just happens to be the last trace line that even a successful seed outputs. A fully-working Rails env on my machine spits out the same output, but works just fine (complete with 0 error code):
$ be rake db:seed --trace
** Invoke db:seed (first_time)
** Execute db:seed
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:abort_if_pending_migrations
$ echo $?
0
For the record, it's expected for db:seed to normally print no output.
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.