Миграция Rails остановлена, хотя таблица не существует

Question

Rails 6
environment: local development on Mac OS
DB server: MySQL

Я удалил все таблицы из БД, и единственные таблицы, оставленные в БД:

schema_migrations
ar_internal_metadata

Я убедился, что в schema_migrations нет данных, и изучил ar_internal_metadata, и эта таблица содержит одну строку со следующими значениями:

key: environment, value: development

У меня есть несколько миграций, последняя из которых - devise_create_users.rb.

Я пытаюсь запустить:

rake db:migrate

Но я получаю сообщение об ошибке:

=> 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

Когда я проверяю БД после этого, я все еще не вижу таблицу пользователей, а таблица schema_migrations по-прежнему опорожнить. Кроме того, миграция DeviseCreateUsers является самой последней, так почему она запускается первой.

Есть идеи?

Редактировать:

На основании комментария к вопросу, Я посмотрел на свой файл database.yml:

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

Я сделал это изменение вчера вечером и забыл, что мои локальные настройки ENV были для другого проекта, поэтому Rails подбирал настройки для этого проекта и был действительно прав, в том, что таблица пользователей уже есть. Исправление было для меня, чтобы создать настройки проекта c ENV, для моей локальной среды разработки

Answer 1

Когда происходят подобные вещи, необходимо проверить database.yml. Как и в большинстве случаев, это происходит из-за неправильной конфигурации.

Хорошо, что только упоминание database.yml в разделе комментариев этого вопроса помогло найти проблему.

Answer 2

Используя rails console, чтобы убедиться, что нет таблицы пользователей, попробуйте создать новый экземпляр User User.new. Если объект был создан, ваша таблица пользователей где-то скрыта. Это не проблема, посмотрите все ранее созданные атрибуты и просто перенесите новые. В вашей миграции devise_create_user я вижу, что вы можете просто заменить ее чем-то вроде addColumnstoUser.rb. Это просто добавит соответствующие столбцы, необходимые для правильной работы Devise.

Выбор этого способа в рамках вашей миграции:

add_column :table_name, :fieldname, :type, в вашем случае, используя только один столбец в качестве примера, это должно быть: def change add_column :users, :reset_password_token, :string end.

Если вы используете контроль версий, например git, миграция может не знать, где вы можете откатиться или go вперед. Все миграции и откаты должны оставаться в одной ветви. Например:

1) Добавление новой ветви для обработки миграции пользователя: git checkout -b generate-user-model, создание модели пользователя rails generate model User name:string email:string и запуск миграции rails db:migrate создаст таблицу пользователей и обновит scheema.rb (проверьте файл схемы). Добавление его к версиям controll git add . и `git commit -m" Перенос модели пользователя "

2) Перемещение в новую ветку git checkout -b comments-controller, генерирование нового контроллера rails generate model Comment. А затем перенести его rails db:migrate.

Эта вторая миграция учит только scheema.rb, как go вперед и как выполнить откат для этой указанной c миграции. Эта последняя ветка git ничего не знает о том, как выполнить откат модели User, если вы не объедините ветку с другой git merge generate-user-model.

После того, как было использовано много миграций, полезно использовать миграции для добавления или удалить таблицы. Следовательно, если у меня есть таблица с именем users и я хочу настроить ее для обработки Devise, мне просто нужно сгенерировать новую миграцию с нужными мне столбцами. Используйте https://sqlitebrowser.org/, чтобы помочь вам проверить таблицы и столбцы базы данных.