Rails migration stopped, even though table does not exist - ruby-on-rails

Rails 6
environment: local development on Mac OS
DB server: MySQL
I deleted all the tables from the DB, and the only tables left in the DB are:
schema_migrations
ar_internal_metadata
I made sure that schema_migrations has no data in it and looked into ar_internal_metadata, and that table has a single row in it, with the following values:
key: environment, value: development
I have several migrations, the most recent one, is devise_create_users.rb.
I am trying to run:
rake db:migrate
But I am getting the error message:
=> rake db:migrate
== 20200317184535 DeviseCreateUsers: migrating ================================
-- create_table(:users)
rake aborted!
StandardError: An error has occurred, all later migrations canceled:
Mysql2::Error: Table 'users' already exists
/Users/dev/rails/myapp/db/migrate/20200317184535_devise_create_users.rb:5:in `change'
Caused by:
ActiveRecord::StatementInvalid: Mysql2::Error: Table 'users' already exists
/Users/dev/rails/myapp/db/migrate/20200317184535_devise_create_users.rb:5:in `change'
Caused by:
Mysql2::Error: Table 'users' already exists
/Users/dev/rails/myapp/db/migrate/20200317184535_devise_create_users.rb:5:in `change'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)
Process finished with exit code 1
class DeviseCreateUsers < ActiveRecord::Migration[6.0]
def change
create_table :users do |t|
t.string :email, null: false, default: ""
t.string :encrypted_password, null: false, default: ""
t.string :reset_password_token
t.datetime :reset_password_sent_at
t.datetime :remember_created_at
t.integer :sign_in_count, default: 0, null: false
t.datetime :current_sign_in_at
t.datetime :last_sign_in_at
t.string :current_sign_in_ip
t.string :last_sign_in_ip
t.timestamps null: false
end
add_index :users, :email, unique: true
add_index :users, :reset_password_token, unique: true
# add_index :users, :confirmation_token, unique: true
# add_index :users, :unlock_token, unique: true
end
end
When I check the DB after this, I still don't see a users table, and the schema_migrations table is still empty. In addition, the DeviseCreateUsers migration is the most recent on, so why is it running first.
Any ideas?
Edit:
Based on a comment to the question, I looked at my database.yml file:
default: &default
host: localhost
database: <%= ENV['RAILS_DB_NAME'] %>
username: <%= ENV['RAILS_DB_USER'] %>
password: <%= ENV['RAILS_DB_PWD'] %>
adapter: mysql2
encoding: utf8mb4
pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
socket: /tmp/mysql.sock
development:
<<: *default
I made that change last night, and I forgot that my local ENV settings, were for a different project, so Rails was picking up the settings for that project, and was indeed correct, in that the users table is already there. The fix was for me to create project specific ENV settings, for my local development environment

When things like this happen it is needed to check the database.yml. As in most cases it happens because of some faulty configuration.
Good thing that just mentioning the database.yml in the comment section of the question helped to find the problem.

Using rails console to make sure there is not any users table, try create a new instance of User User.new. If the object was instanciated, your User table is hidden in somewhere. It is not a problem, see all atributtes previously generated and just migrate new ones. I can see in your devise_create_user migration that you can just replace it with something like addColumnstoUser.rb. This will just add the apropriated columns necessary to let Devise runing well.
Choosing this way, inside your migration:
add_column :table_name, :fieldname, :type, in your case, using just one column as an example, it must be:
def change
add_column :users, :reset_password_token, :string
end.
If you are using version controll, such as git, the migration might not know where you can rollback or go ahead. All the migration and rollbacks must stay on the same branch.
For example:
1) Adding a new branch to handle user migration: git checkout -b generate-user-model, generating user model rails generate model User name:string email:string
and running the migration rails db:migrate will create the users table and will update scheema.rb (check scheema file). Adding it to version controll git add . and `git commit -m "Migrating user model"
2) Moving to a new branch git checkout -b comments-controller, generating a new controller rails generate model Comment. And then migrating it rails db:migrate.
This second migration only teachs scheema.rb how to go ahead and how to rollback on this specifc migration. This last git branch doesn't know nothing about how to rollback the User model, unless you merge a branch inside another git merge generate-user-model.
After many migrations has been used, it's usefull keep using migrations to add or delete tables.
Hence, If I had a table called users and I wanted to set it to handle Devise, I just need to generate a new migration with the columns I'd needed.
Use https://sqlitebrowser.org/ to help you cheking your database tables and columns.

Related

Is 'Archive' a reserved word in Rails or SQLite3?

After migrating a model named 'Archive', all tests fail with an ActiveRecord / error message along the lines of:
ActiveRecord::NotNullViolation: SQLite3::ConstraintException: NOT NULL constraint failed: archives.created_at: INSERT INTO "archives" ("some_thing") VALUES ('MyString')
This was isolated in a new Rails app on a new VM running a fresh install of Ubuntu 18.04.2 with Ruby 2.6.1 and Rails 5.2.3, following The Odin Project's installation instructions. The problem only arises during tests for models named 'Archive', and removing the model's attributes just changes the error to:
ActiveRecord::StatementInvalid: SQLite3::SQLException: incomplete input: INSERT INTO "archives"
My work flow is as follows:
rails new sample_app
cd sample_app
(change sqlite3 in Gemfile to use version '~> 1.3.6' to fix bug at time of this writing)
bundle install
rails g model Archive
Generates this migration:
class CreateArchives < ActiveRecord::Migration[5.2]
def change
create_table :archives do |t|
t.timestamps
end
end
end
rails db:migrate
Creates this schema:
ActiveRecord::Schema.define(version: 2019_04_03_003144) do
create_table "archives", force: :cascade do |t|
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end
end
rails db:test
Runs this test: (uncommented)
require 'test_helper'
class ArchiveTest < ActiveSupport::TestCase
test "the truth" do
assert true
end
end
After running the test, which would normally be a given pass, Rails returns the first ActiveRecord error message listed above.
I feel like I am missing something here that prevents me from using the word 'Archive' for a model.
Archive is not a reserved word. The link you have provided is not updated in last 5 years.
The reason behind this is:
You are creating a record of Archive without providing created_at and updated_at which are mandatory fields as per your schema.
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
Solution:
Either change your migrations to allow null to be inserted in created_at and updated_at OR go to you test/fixtures/archive.yml and provide created_at and updated_at there.
like:
one:
....some fields....
created_at: 2018-08-30 14:41:23
updated_at: 2018-08-30 14:41:23
UPDATE
Now second issue is because you don't have any field other than timestamp. Drop this table and create new model for Archive with at least 1 field. Currently Rails is generating query INSERT INTO "Archives"; and SQL expects data after this query, that's why it returns error to you.

Error ActiveRecord::PendingMigrationError

I am following Michael Hartl's book and I am getting this error when I run the server:
I am getting ActiveRecord::PendingMigrationError when I run the server, this shows up:
Migrations are pending. To resolve this issue, run: bin/rails db:migrate RAILS_ENV=development
Please I've been stuck in this error for so long.
When I type $ RAILS_ENV=development rake db:migrate I get this error:
== 20161209073230 AddActivationToUsers: migrating =============================
-- add_column(:users, :activation_digest, :string) rake aborted! StandardError: An error has occurred, this and all later migrations
canceled:
SQLite3::SQLException: duplicate column name: activation_digest: ALTER
TABLE "users" ADD "activation_digest" varchar
(required)>' Tasks: TOP => db:migrate (See full trace by running task
with --trace)
test/mailers/previews/user_mailer_preview.rb
UserMailerPreview < ActionMailer::Preview
# Preview this email at
http://localhost:3000/rails/mailers/user_mailer/account_activation
def account_activation
user = User.first
user.activation_token = User.new_token
UserMailer.account_activation(user) end
# Preview this email at
http://localhost:3000/rails/mailers/user_mailer/password_reset def
password_reset
UserMailer.password_reset end
end
Schema.rb:
# This file is auto-generated from the current state of the database. Instead
# of editing this file, please use the migrations feature of Active Record to
# incrementally modify your database, and then regenerate this schema definition.
#
# Note that this schema.rb definition is the authoritative source for your
# database schema. If you need to create the application database on another
# system, you should be using db:schema:load, not running all the migrations
# from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).
#
# It's strongly recommended that you check this file into your version control system.
ActiveRecord::Schema.define(version: 20161123005710) do
create_table "users", force: :cascade do |t|
t.string "name"
t.string "email"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
t.string "password_digest"
t.string "remember_digest"
t.string "activation_digest"
t.index ["email"], name: "index_users_on_email", unique: true end
end
Latest migration is
db/migrate/[timestamp]_add_activation_to_users.rb:
class AddActivationToUsers < ActiveRecord::Migration[5.0]
def change
add_column :users, :activation_digest, :string
add_column :users, :activated, :boolean, default: falserao
add_column :users, :activated_at, :datetime
end
end
The correct command to apply unapplied migrations is RAILS_ENV=development rake db:migrate
This just means that you have a migration pending. When you create a new migration
railas g migration MigrationName
it means that it changes something in the database schema or the layout of your database. In order to commit that change, you have to run:
bin/rails db:migrate
This will look into your migration file and apply it to your databse. Once the migration is done, you can run server as usual again.
rails server
If you have more question, I recommend reading the migration documentation that Rails published:
http://guides.rubyonrails.org/active_record_migrations.html
SQLite3::SQLException: duplicate column name: activation_digest:
(The following is the SQL command that actually modifies the db):
ALTER TABLE "users" ADD "activation_digest"
The SQL command reads like plain English. Somehow one of your migrations is doing something a previous migration already did, namely adding the activation_digest column to your users table in the db. If you look in the directory db/migrate/, you will see all your migration files. If you open one of them up, you should sort of be able to tell what it is doing. So look at all your migration files and find the two migrations that both add the activation_digest column. If the two migration files are identical, then you need to delete one--but take the following steps before deleting a migration:
https://www.baserails.com/questions/i-messed-up-while-generating-my-migration-how-can-i-undo-it
Also check out the section Rolling Back in the Rails Guide:
http://edgeguides.rubyonrails.org/active_record_migrations.html#reverting-previous-migrations
If for some reason you don't have two identical migration files that both add the activation_digest column, e.g one of the migration files does something additionally, then you need to figure out what steps in the tutorial that you did wrong, then rollback to the last migration that you know is correct. Finally, follow the steps in the tutorial again for generating the subsequent migrations.
It seems your users table already have a column named activation_digest. Remove the add_column line where the column is added from the migration file and run the migration again.
I think this migration file should work:
class AddActivationToUsers < ActiveRecord::Migration[5.0]
def change
add_column :users, :activated, :boolean, default: false
add_column :users, :activated_at, :datetime
end
end
Ok the answer is very simple!Just try migrating your DB to version=0 with command: rake db:migrate VERSION=0
and then run rake db:migrate

schema.rb doesnt include add_index method after migration using postgresql

So I was trying to create a database index on the email column of a Users model, but I must be doing something wrong, since after I do the migration I go and check on the schema.rb file to see if the add_index method is included and nothing shows up. I am using postgresql, by the way. So here is what I did...
I created the migration
rails generate migration add_index_to_users_email
After that, I edited and saved the db/migrate/20140911192804_add_index_to_users_email.rb file with the following code for indexing:
class AddIndexToUsersEmail < ActiveRecord::Migration
def change
add_index :users, :email, unique: true
end
end
After that I ran on the console
bundle exec rake db:migrate
And when I went to check on the schema.rb file to see if the add_index method was included, I found that it wasnt there. Here is what my schema.rb looked like
ActiveRecord::Schema.define(version: 20140911192804) do
# These are extensions that must be enabled in order to support this database
enable_extension "plpgsql"
create_table "users", force: true do |t|
t.string "name"
t.string "email"
t.datetime "created_at"
t.datetime "updated_at"
end
end
I tried to run rake db:rollback to run again db:migrate and see if some "magic" occurred but I wasnt even able to rollback, getting this error message:
== AddIndexToUsersEmail: reverting ===========================================
-- remove_index(:users, {:unique=>true, :column=>:email})
←[1m←[35m (0.0ms)←[0m ROLLBACK
rake aborted!
An error has occurred, this and all later migrations canceled:
Index name 'index_users_on_email' on table 'users' does not existC:in `migrate'
Tasks: TOP => db:rollback
I'm pretty lost... something that i found interesting was that in the schema.rb file this line
ActiveRecord::Schema.define(version: 20140911192804) do
had the same timestamp as the migration file for the add_index db/migrate/20140911192804_add_index_to_users_email.rb
So there was some sort of update on the schema.rb file during the migration but not what I was expecting to occur.
I don't even know where to start :D so I hope someone a bit more experienced can give me a hint.
Thanks so much!
After hours of trial and error I could finally find a solution!
For some reason beyond my understanding, the migration didnt add the add_index method to my schema.rb, however, when I tried to rollback, it was looking for an index in the users table that didnt exist, so it kept aborting the rollback.
I assumed that the info about the index that it had to look for in the table was in the migration file. So I deleted the content of the migration file leaving it like this:
class AddIndexToUsersEmail < ActiveRecord::Migration
def change
end
end
I was finally able to rollback.
Then I typed again the content inside the AddIndexToUsersEmail migration file
class AddIndexToUsersEmail < ActiveRecord::Migration
def change
add_index :users, :email, unique: true
end
end
I ran again bundle exec rake db:migrate
and it worked! :D
Thanks a lot to everyone who took their time to read this issue!
I just had the same problem and found why !!!
You (we) used the migrate command before saving the migrate file !! So the migration was passed with nothing inside. Just a change method with no instructions.
And if after you try to rollback and the migration file have been saved since. The add_index instruction is in so it can't rollback.
I hope i am clear enough.

Failure to Create Table on Heroku -- Migration works locally but fails on Heroku

I'm working on a Rails 3 app and am trying to run a migration. I am trying to create a table called Songs and I was able to successfully create the table and migrate locally. However, when I push the code to Heroku and migrate there, the error I encounter is:
** Execute db:migrate
== CreateSongs: migrating ====================================================
-- create_table(:songs)
NOTICE: CREATE TABLE will create implicit sequence "songs_id_seq1" for serial column "songs.id"
rake aborted!
An error has occurred, this and all later migrations canceled:
PG::DuplicateTable: ERROR: relation "songs" already exists
: CREATE TABLE "songs" ("id" serial primary key, "solo_cello" character varying(255), "created_at" timestamp, "updated_at" timestamp) /app/vendor/bundle/ruby/1.9.1/gems/activerecord-3.1.12/lib/active_record/connection_adapters/postgresql_adapter.rb:605:in `async_exec'
I realize this error stems from the table already existing in the database, however when I run
heroku run "bundle exec rake db:schema:dump && cat db/schema.rb"
I see that the schema version is at ActiveRecord::Schema.define(:version => 20130915155113) and the migration to create the Songs model occurs after this migration (it is 20140506043817).
Here's is a truncated version of my local schema:
ActiveRecord::Schema.define(:version => 20140511155456) do
[other tables...]
create_table "songs", :force => true do |t|
t.string "solo_cello"
t.datetime "created_at"
t.datetime "updated_at"
t.string "solo_violin"
t.string "duo_one"
t.string "duo_two"
t.string "trio_a_one"
t.string "trio_a_two"
t.string "trio_a_three"
t.string "trio_b_one"
t.string "trio_b_two"
t.string "trio_b_three"
t.string "quartet_one"
t.string "quartet_two"
t.string "quartet_three"
t.string "quartet_four"
end
Here are my questions:
How does the table already exist if the schema on the database is at version 20130915155113 if the migration that creates the Song table (20140506043817) comes later?
What do I need to do to run a successful migration? I realize I can drop the database (this is the staging environment) but would greatly prefer not to do that on production.
Why do migrations work fine on my machine locally but not on Heroku?
Sounds like your songs table might have been left behind as effect of restoring a database backup. Restoring a database backup on Heroku will only rewrite tables which exist in the backup, but it won't drop tables which didn't yet exist when the backup was created.
There are several steps to follow to resolve the issue:
Drop the table. You can manually drop the table by running heroku pg:psql in the terminal, and then executing the query DROP TABLE songs;. If this was the only problematic table, you can now run your migrations.
Drop the database. In case you have a database backup and you can afford some downtime, you can also drop the database by running heroku pg:reset from the terminal, then restoring your database backup and running your migrations.

ruined database through 'rake db:setup'? (RoR)

Yesterday, i was tryin' to setup up a fulltext search-engine named "Elasticsearch" and i followed the instructions on Railscasts.com (http://railscasts.com/episodes/306-elasticsearch-part-1?view=comments&_=1345840910957) to integrate this search-engine onto my website.
I followed the tasks to the point where to call 'rake db:setup' and it "recreated" my whole database (didn't wanted that) and now nothing works. It seems like Rails recreated the db from the schema.rb, but it only creates the tables and the indexes and not the associated columns with it.
http://img14.imageshack.us/img14/1535/bildschirmfoto20120825u.png
Im on _development db.
Running rake db:setup looked like this:
doanything_development already exists
doanything_test already exists
-- create_table("admin_notes", {:force=>true})
NOTICE: CREATE TABLE will create implicit sequence "admin_notes_id_seq" for serial column "admin_notes.id"
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "admin_notes_pkey" for table "admin_notes"
-> 0.1088s
-- add_index("admin_notes", ["admin_user_type", "admin_user_id"], {:name=>"index_admin_notes_on_admin_user_type_and_admin_user_id"})
-> 0.0064s
-- add_index("admin_notes", ["resource_type", "resource_id"], {:name=>"index_admin_notes_on_resource_type_and_resource_id"})
-> 0.0049s ...<br /><br />
Schema.rb looks like: " create_table "users", :force => true do |t|<br />
t.string "name"
t.string "email"
t.datetime "created_at",:null => false
t.datetime "updated_at",:null => false ... end <br />
And it created on my pgdb table "Sequences" columns like "users_id_seq", which i hadn't before. Running 'rake db:migrate' doesn't load any of the existing migrationfiles: e.x.
class AddSaltToUsers < ActiveRecord::Migration <br/>
def change <br/>
add_column :users, :salt, :string <br/>
end
end
versions are : ruby 1.9.3p194, Rails 3.2.6 and PostgreSQL 9.1.4
If someone could figure out what just happenend and how i can get my site working again.
If you ran rake db:migrate once. The migration for AddSaltToUsers may have already ran. If so, there are a few ways to overcome this.
Either create a new migrations file, or manually edit schema_migrations, by removing the version number from that table and then re-running rake db:migrate. I would highly not recommend doing the latter, as it can screw up your migrations all together if you don't know what you are doing.
Hope that helps.

Resources