Here is the basics. I had a deployment on a SANDBOX environment.
I made some changes, and attempted to redeploy. The Stack is Cap3 with a Postgres DB / Rails 4.2
Upon deployment, which has never had any issues prior, when it came to run the migrations, which it shouldn't have because there were no pending ones, it basically rolled back all of the migrations to a 0 state.
I successfully created this error in the development environment.
I had to recover the schema file from a previous commit, because the reversion of course rolled everything back.
so right now.
ActiveRecord::Schema.define(version: 20151214201502) do ...
And the last migration file is
20151214201502_create_host_group_membership_table
When I try and deploy, or run rake db:migrate I get a total reversion. All tables get dropped.
Schema.rb reads ActiveRecord::Schema.define(version: 0) do
and the rake db:migrate:status reads >
Status Migration ID Migration Name
--------------------------------------------------
down 20150916151324 Create ...<edited> table
down 20150916190627 Create ...<edited> table
down 20150916195012 Create ...<edited> table
down 20150918112956 Create ...<edited> table
down 20151019175551 Create ...<edited> table
down 20151020195644 Create ...<edited> table
down 20151020202321 Create ...<edited> table
down 20151026021111 Create ...<edited> table
down 20151124161525 Create ...<edited> table
down 20151124185807 Create ...<edited> table
down 20151214201502 Create ...<edited> table
and any subsequent rake db:migrate results in nothing.
If you overwrite the ENV["VERSION"], the rake db:migrate will go downgrade rather than upgrade if VERSION is smaller than last known VERSION in db schema, so please check and avoid similar environment variable.
I had exactly the same issue, but Eric's answer didn't work in my case.
What did the trick was to drop the db, erase the schema and create and migrate the db:
$ rails db:drop
$ rm db/schema.rb
$ rails db:create
$ rails db:migrate
Related
I have a strange issue with migrations. The last migration file is: 20190826113704_add_percentage_account_to_contacts.rb.
The timestamp in schema.rb is ActiveRecord::Schema.define(version: 2019_08_26_113704).
So you would say everything is up to date. When I start the server and go to the site I get the Migrations are pending error. So when I run rails db:migrate I get an error relation "study_agreements" already exists which is correct, there are no migrations pending.
So how can I solve this?
The issue is your database reflects that migration is loaded but somehow the entry in schema_migrations either got deleted(accidentally or through migration rollback).
Steps to solve this issue:
Identify the migration(migration number) from db/migrations where study_agreements relation was introduced. Let's say it is 1234
Now manually create an entry in schema_migrations table in your DB. For example in MySQL you can do "INSERT INTO schema_migrations (version) values(1234)".
Another solution is: Run rake db:migrate after commenting the change or up method of your migration in which study_agreements relation was introduced.
It seems you have already have a table in DB and you have down migrated file in your migrate folder. you can do 2 things here:
Run rails db:schema:load
OR
If you don't have data in your db then run rails db:reset
I am trying to find the correct (any) method to create an application in Ruby on Rails having an existing database (PostgreSQL) with data and fresh app made with:
rails new --database=postgresql -J --skip-coffee .
I found https://github.com/frenesim/schema_to_scaffold but first I need to have a file with a database structure: schema.rb. I’m looking for a way to do it automatically.
In result of rake db:schema:dumpfile schema.rb is generated, but only with content like that:
ActiveRecord::Schema.define(version: 0) do
enable_extension "plpgsql"
end
And I stuck here. Why that file is empty? Why are there no tables here?
I have a connection with DB and no errors. I did rake db:create before to test. Creation of bases described in database.yml is successful.
At the beginning I used Docker containers and this is my goal. But to exclude the probability of error, I installed the environment in the system (macOS Mojave) based on the socket. And I’ve got the same effect.
How to generate schema.rb with structure of existing database? Or is there different way to build RoR app based on the existing data structure?
Update: Connection with the new database I only did for testing purposes. To verify configuration.
Here's what else I did:
Dump existing structure with
pg_dump --schema-only app_development > db/structure.sql
I changed name in database.yml to have fresh place to import.
rake db:setup created new DB
rake db:structure:load create tables from db/structure.sql file in DB correctly.
But rake db:schema:dump still generate empty file as earlier.
If you have set proper db config you can use rake db:migrate to regenerate the schema file.
edit:
Ok so lets check if I understood correctly:
you have an existing db with tables and data in it
you have brand new rails app
you want to reflect db structure in you schema.rb file
Is that correct? If yes then like I wrote before - without adding any new migrations to your codebase, run rake db:migrate. That task not only applies changes from the migration file but also updates your schema file to be in sync with the actual database.
I've got it! Two days of my life.
File used to import PostgreSQL database has at the beginning:
CREATE SCHEMA employees;
-- and later
CREATE TABLE employees.department;
I thought that since Rails generates database by rake db:structure:load , the file's syntax is correct.
But when I create manually table users in new empty database and then pg_dump that new base I don't have CREATE SCHEMA query there.
And finally rake db:schema:dump fills schema.rb with tables as I want:
create_table "users", id: :serial, force: :cascade do |t|
t.text "name"
end
Because that fresh pg_dumped file has CREATE TABLE public.users query. public.
I think the key is in comments in database.yml file:
# Schema search path. The server defaults to $user,public
#schema_search_path: myapp,sharedapp,public
One picture is more valuable than a thousand words: that's the differences Table users on the right goes to schema.rb after rake db:schema:dump
Thanks guys for the comments. It's made sure me that I do not make a terrible mistake.
It sounds like you did rake db:create which creates a new database for you and then did rake db:schema:dump which generated a schema.rb file for you from the newly created (empty) database.
If you have an existing database that you want to use you will need to modify your database.yml file to connect to it.
If you want to create a new database you will need to generate Active Record database migrations e.g.) rails generate migration CreateProducts name:string part_number:string and then run them rake db:migrate to update your database and generate your schema.rb.
Still a newbie. I'm working on a new feature for a RoR app. I created a local branch and generated a migration. Unfortunately I didn't save my changes to the migration file and then ran db:migrate. Wanting to start over, I switched back to master and repulled from my git and did a hard reset with the following commands (I never committed the files in the branch either locally or remotely):
git fetch --all
git reset --hard origin/master
I then remade a local branch, recreated the migration (correctly this time) and ran db:migrate. I get an error that the table already exists in the database, however, when I look in schema.db the table isn't there.
All I want is to go back to where I was based on the remote git. For what it's worth, I'm using Cloud9 on AWS for development. Thanks!
There is nothing to do with database when you make changes regarding git. Once you run rake task like rake db:migrate to make database changes, it will get reverted automatically once you change branch, You have to prepare rollback steps. (As down methods in migrations are run conventionally)
Your old migration version was different than new recreated migration so application tried to run migration file without checking whether table exists.
Whenever you run rake db:migrate in for particular database, it store migration version in your schema_migrations table in db. So calling again and again same rake will not try to create table with same name. In above case you have different migration files to create same table and schema_migration table do not know whether you deleted branch with old migration file or whether table already exists
So run following in your rails console,
ActiveRecord::Migration.drop_table :table_name
And then run your rake db:migrate
Recently I implemented friendy_id on my rails application. So I generate new column called slug in my existing ActiveRecord model called Category. Everything is working fine. Both my local code and production have same tables and columns. The same code is running on production.
Every now and then I take the mysql database dump from the production server and try to import it to the source code on my local machine. Before I run rake db:migrate I always do rake db:drop and rake db:create.
So After importing the dump I do drop and create and then run rake db:migrate. It fails. Saying Duplicate column slug from categories
So what I've been doing so far is, every time I import dump from production, I am supposed to drop the slug column by doing
ALTER TABLE categories DROP COLUMN slug;
Then When I run rake db:migrate. It runs the last migrations which is created slug for categories. And then the migration ends successfully.
How can I overcome this issue ? I am forced to this every time I want to import the production db to local.
Sounds to me like your schema_migrations tables are no synced between production and development. So rails tries to migrate the last migration (adding slug) which is already added in the database, hence the error.
I have a migration with version number 20120926232105. My schema is at version 20121003190827.
My site is hosted on Heroku, and when I run
heroku run rake db:migrate -a my-app
I get an error that the table it is trying to create in migration 20120926232105 already exists (as it should). I don't get it - isn't the whole point of the schema_migration table to record which was the last successful migration?
This guy explains it pretty well.
Basically, there's a table somewhere called "schema_migrations". Your migration's "version number" is actually just a time stamp. Further, there's no record of a migration with that timestamp in your 'schema_migrations' table. Since the migration exists, and its timestamp wasn't found in the 'schema_migrations' table, Rake knows to run it.
Try grep -r "table_name" db/migrate and see if it's in there twice.