rails: таблица уже существует в новой ветке git

Question

Я пытаюсь поиграть с разными жемчужинами сообщений, которые все используют. Поэтому, после установки Devise на основную ветку git, я извлек новую ветку, чтобы попробовать один гем "rails messaging" https://github.com/frodefi/rails-messaging,, и когда я не смог заставить его работать, я зафиксировал изменения в этой ветке, и затем я вернулся к мастеру и проверил новую ветку, чтобы попробовать другой гем "mailboxer" https://github.com/ging/mailboxer/tree/master/lib. В файле gemfile этой новой ветки не было никаких следов драгоценных камней из первой ветки, однако, когда я попробовал рейк db: перенос для этой второй ветви после установки гемов, я получил это сообщение об ошибке, которое, казалось, предполагало, что таблица из первой ветви вмешивалась в грабли второй ветви, если только

 rails g mailboxer:install

Он автоматически запускает грабли db: migrate. Однако README говорит, что мне нужно запустить rake db: migrate, так что я не уверен ...

rake aborted!
An error has occurred, this and all later migrations canceled:

SQLite3::SQLException: table "conversations" already exists: CREATE TABLE "conversations" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "subject" varchar(255) DEFAULT '', "created_at" datetime NOT NULL, "updated_at" datetime NOT NULL

)

Кто-нибудь может подсказать, как я могу обойти это? Я действительно не знаю, какие команды запустить, чтобы понять это.

Это файл sche.rb. Основываясь на индексе «пользователи сообщений», я предполагаю, что это установка, созданная гемом сообщений rails (в первой ветви), но я не совсем уверен. Я посмотрел исходный код на git, но немного потерян, потому что я не очень опытен.

ActiveRecord::Schema.define(:version => 20120302041333) do

  create_table "conversations", :force => true do |t|
    t.string   "subject",    :default => ""
    t.datetime "created_at",                 :null => false
    t.datetime "updated_at",                 :null => false
  end

  create_table "messaging_users", :force => true do |t|
    t.string   "email",                                 :default => "", :null => false
    t.string   "encrypted_password",     :limit => 128, :default => "", :null => false
    t.string   "reset_password_token"
    t.datetime "reset_password_sent_at"
    t.datetime "remember_created_at"
    t.integer  "sign_in_count",                         :default => 0
    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.datetime "created_at"
    t.datetime "updated_at"
  end

  add_index "messaging_users", ["email"], :name => "index_messaging_users_on_email", :unique => true
  add_index "messaging_users", ["reset_password_token"], :name => "index_messaging_users_on_reset_password_token", :unique => true

  create_table "notifications", :force => true do |t|
    t.string   "type"
    t.text     "body"
    t.string   "subject",              :default => ""
    t.integer  "sender_id"
    t.string   "sender_type"
    t.integer  "conversation_id"
    t.boolean  "draft",                :default => false
    t.datetime "updated_at",                              :null => false
    t.datetime "created_at",                              :null => false
    t.integer  "notified_object_id"
    t.string   "notified_object_type"
    t.string   "notification_code"
  end

  add_index "notifications", ["conversation_id"], :name => "index_notifications_on_conversation_id"

  create_table "receipts", :force => true do |t|
    t.integer  "receiver_id"
    t.string   "receiver_type"
    t.integer  "notification_id",                                  :null => false
    t.boolean  "read",                          :default => false
    t.boolean  "trashed",                       :default => false
    t.boolean  "deleted",                       :default => false
    t.string   "mailbox_type",    :limit => 25
    t.datetime "created_at",                                       :null => false
    t.datetime "updated_at",                                       :null => false
  end

  add_index "receipts", ["notification_id"], :name => "index_receipts_on_notification_id"

  create_table "users", :force => true do |t|
    t.string   "email",                                 :default => "", :null => false
    t.string   "encrypted_password",     :limit => 128, :default => "", :null => false
    t.string   "reset_password_token"
    t.datetime "reset_password_sent_at"
    t.datetime "remember_created_at"
    t.integer  "sign_in_count",                         :default => 0
    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.datetime "created_at"
    t.datetime "updated_at"
    t.string   "name"
  end

  add_index "users", ["email"], :name => "index_users_on_email", :unique => true
  add_index "users", ["reset_password_token"], :name => "index_users_on_reset_password_token", :unique => true

end

Answer 1

Проблема здесь в том, что хотя ваш код, схемы, гемы и миграции хранятся в git, сама база данных - нет. Поэтому при переключении между ветвями база данных все еще сохраняет свое состояние.

Все эти решения будут работать:

1. удалить и заново заполнить вашу базу данных

   rake db:reset
   

2. выполнить миграцию вниз (пока на старой ветке), чтобы отменить миграцию. Я не уверен, установил ли гем миграцию в db / migrate или запустил миграцию непосредственно из гема, так что это не так просто, но лучше для целостности данных, если вы не хотите стереть свои данные.

3. перезагрузить схему, которую вы сохранили в git (это имеет тот же эффект, что и первая)

   rake db:schema:load
   

4. пока используйте базу данных sqlite - хотя она и не подходит для производства, если вы включите в git базу данных, она будет вести себя так, как вы хотите, чтобы ваша текущая база данных вела себя. Я должен предупредить вас, что большие файлы, как это будет боль. Лучше использовать один из других подходов.

Answer 2

Да, переключение веток с разными уровнями миграции - беспорядок. Не существует «одной строки», чтобы сделать это правильно. Есть четыре вещи, которые могут быть не синхронизированы. Вам нужно:

1) Определите, какие миграции имеет ваша ветвь:

(look at the contents of db/migrations)

2) Определите, как ваше приложение считает вашу базу данных:

(look at db/schema.rb)

3) Определите, какие миграции ваша база данных считает, взглянув на таблицу schema_migrations:

~> rails db console

(opens up your db console, in my case mysql...)

mysql> SELECT * FROM schema_migrations; # don't forget the ';' at the end!

(outputs big huge list of migration timestamps)

4) Посмотрите на реальные таблицы, чтобы увидеть, были ли применены миграции.

mysql> describe table_name;

(outputs the column names, see if they have been updated per the migration)

5) Теперь часть, которая требует мышления. Есть несколько возможных сценариев. Я могу говорить только с тем, с кем столкнулся:

• Ваши файлы миграции (1), ваши schema.rb (2) и ваши фактические таблицы (4) совпадают, но в вашей таблице schema_migrations (3) отсутствует метка времени миграции. Это была моя проблема.
  • Если вам не нужны данные: rake db:reset. Это уничтожит всю вашу базу данных и воссоздаст структуру с нуля
• Пожалуйста, предложите другие сценарии с решениями ..