Ruby on Rails. Why schema.rb builded on existing data through db:schema:dump is almost empty? - ruby-on-rails

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.

Related

Migrations are pending error while everything is up to date

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

Rails db migrate generate migrate file

When working on a project, I keep track of all the changes I make to a database in a notepad file. Then, later, I manually write all the changes in rails' db migration file.
But it should be possible to compare the schema of a backup of my database, with the new version of my database, and automatically detect the differences. And generate the rails db migration file automatically.
Is there a tool that can compare two database schema's and automatically generate rails' db migration files?
As far as I'm aware, there's no tool that will do it automatically, however, you can get most of the way there just using rake db:schema:dump with source control.
Create a new Rails project and do the following:
Update database.yml to connect to your first database.
Use rake db:schema:dump to populate schema.rb and commit schema.rb to git.
Update database.yml to connect to your second database and again run rake db:schema:dump
Use git diff on schema.rb to compare the changes. This can easily be mapped to a migration.
The benefit of using source control is that you can then test the migration by comparing schema.rb after the migration runs to the schema dump of the second database.

Rails schema & migrate keeps reverting to a VERSION=0

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

Can Rails schema table be outside the database?

We have a legacy PostgreSQL database that is perfectly accessible from a Rails app except that when the vendor provides an update one of the consistency checks they perform against the database fails because Rails has built a "new" table there, the schema migrations table. Is it possible to direct creation of this table elsewhere? Or is it possible to use the schema cache in Rails 4 to effect this? The release notes section 3.3 on General things says "Schema cache dump (commit) - To improve Rails boot time, instead of loading the schema directly from the database, load the schema from a dump file."
I found an old blog post about this last time I tried it here. Copying the relevant parts:
To make a dump of your schema, execute the following rake task:
RAILS_ENV=production bundle exec rake db:schema:cache:dump
This will generate a file db/schema_cache.dump, that Rails will use to load the internal state of the SchemaCache instance.
To disable the schema cache dump, add the following to your config/production.rb file:
config.active_record.use_schema_cache_dump = false
If you would like to clear the schema cache, execute:
RAILS_ENV=production bundle exec rake db:schema:cache:clear

Modify schema.rb in rails application

I am new to rails.
I want to create an Article model. So I run,
rails g model Article name:string context:string
Instead of content I type in context, Is there a way to update the schema.rb file that gets generated?
I would like the articles table to have name and content columns.
Don't focus on schema.rb -- this is just a dump of the current state of your database. Instead, what you need to do is correct the migration file. It is the migration files that actually define what tables/column will exist in production in the end so they must be correct. I'd recommend:
Run ls -ltr db/migrate -- use this to find your migration file and copy the date string. Rails uses this as the "version" of the migration. For example: "20140809165359_create_articles", the version is "20140809165359".
Run bundle exec rake db:migrate:down VERSION=20140809165359 (replace the version number with your own, here)
Now go fix your migration file (change "context" to "content")
Run bundle exec rake db:migrate to migrate back up.
This will fix the underlying problem and you'll notice that now, after migrating back up, your schema.rb will be fixed too.

Resources