Schema.rb запутался из-за миграции в других ветвях

В настоящее время я работаю с огромным рельсовым приложением и несколькими ветвями с каждой новой функцией для этого приложения. Это случается очень часто, когда функция требует миграции, которая не должна быть проблемой, пока вы не объедините ее с мастером: schema.rb обновлен с информацией о вашей базе данных разработчиков!

Чтобы уточнить:

1. Branch A has migration create_table_x
2. Branch B has migration create_table_y
3. Branch A adds another create_table_z and runs db:migrate
4. You want to merge Branch A with Master and you see table_x, table_y and table_z in the schema.rb of Branch A.

Это не опция reset + засеять базу данных до каждой миграции в ветке или создать базу данных для каждой ветки. Из-за огромного размера данных объемом 2 ГБ SQL это не будет работоспособным.

Мой вопрос:

Действительно ли требуется сохранить schema.rb в репозитории, поскольку он перестраивает каждую миграцию?

Если да, возможно ли построить схему с миграций вместо дампа базы данных?

Ответ 1

вы должны сохранить схему в своем репо. при выполнении миграции будут исправлены конфликты слияния в файле schema.rb для вас. мои простые ответы на ваши вопросы

Обязательно? не очень, но хорошая практика.

"Настоятельно рекомендуется проверить этот файл в вашей версии системы управления." -schema.rb

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

вы добавили преимущество использования

rake db:schema:load

rake db:schema:dump

http://tbaggery.com/2010/10/24/reduce-your-rails-schema-conflicts.html

Ответ 2

Сохранение schema.rb в репо важно, потому что вы хотите, чтобы новый разработчик (или ваша тестовая среда) мог создавать новую базу данных только из schema.rb. Когда у вас много миграций, они могут не все продолжать работать, особенно если они полагаются на классы моделей, которые не существуют или не изменились или имеют разные проверки, чем при первом запуске миграции. Когда вы запускаете свои тесты, вы хотите сбросить и воссоздать свою базу данных из schema.rb, а не повторно запускать все миграции каждый раз, когда вы запускаете полный набор тестов.

Если вы работаете одновременно с двумя разными ветвями функций и изменяете структуру базы данных в обоих, я думаю, что schema.rb является наименьшей из ваших проблем. Если вы переименуете или удалите столбец в ветки B, ветвь A будет разбиваться всякий раз, когда она ссылается на старый столбец. Если все, что они делают, это создание новых таблиц, это не так плохо, но тогда вы хотите, чтобы schema.rb обновлялся при слиянии с мастером в A, так что A не пытается запустить миграцию во второй раз и не выполнить потому что новая таблица уже существует.

Если это не ответит на ваш вопрос, возможно, вы могли бы объяснить свой рабочий процесс немного больше?

Ответ 3

Свежая временная БД как быстрое обходное решение

Например, выполните следующие действия, когда вам понадобится довольно db/schema.rb в конкретной ветке:

git checkout - db/schema.rb
переключиться на другую базу данных разработки, то есть обновить config/database.yml
rake db: drop && & rake db: setup
rake db: migrate
сделайте свой симпатичный db/schema.rb
вернуть изменения в config/database.yaml