schema.rb перепутался из-за миграций в другие ветки

В настоящее время я работаю с огромным приложением rails и несколькими ветвями, каждая из которых представляет собой новую функцию для этого приложения. Бывает, что функция потребует миграции, что не должно быть проблемой, пока вы не объедините ее с мастером: 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.

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

Мой вопрос:

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

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


ruby-on-rails rails-migrations schema.rb
person Vikko    schedule 08.05.2013    source источник
comment
Я думаю, вы должны хранить свой schema.rb в своем репозитории. Может случиться так, что кто-то очистит файлы миграции и удалит несколько неиспользованных миграций из прошлого ... и если у вас нет единого schema.rb, я могу оказаться в беспорядке. файл схемы обновляется при каждой миграции, а не полностью перестраивается. но в любом случае интересный вопрос.   -  person Matthias    schedule 08.05.2013
comment
да, проблема в том, что она создается из текущей структуры базы данных, независимо от того, были ли таблицы в базе данных добавлены в родительскую или в ветку, в которой вы находитесь. Вот что я имел в виду под «перестроением». Я надеюсь, что кто-то знает более приятный способ, чем удаление/копирование базы данных из мастера каждый раз, когда вы переключаете ветку с миграциями :)   -  person Vikko    schedule 08.05.2013
comment
Возможный дубликат Каков предпочтительный способ управления схема.rb в git?   -  person Tachyons    schedule 07.04.2017

Ответы (3)


arrow_upward
10
arrow_downward

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

  1. Требуется ли это? не совсем, но хорошая практика.

«Настоятельно рекомендуется зарегистрировать этот файл в вашей системе контроля версий». -schema.rb

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

вы получаете дополнительную выгоду от использования

rake db:schema:load

и

rake db:schema:dump

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

person Stephen Nguyen    schedule 18.06.2013

arrow_upward
2
arrow_downward

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

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

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

person sockmonk    schedule 08.05.2013
comment
Это правильно, но вы не хотите, чтобы таблицы ветки B (где вы выполнили миграцию) отображались в мастере ДО того, как вы объедините ветку B. Например: если есть таблица, которая используется как в ветке A, так и в ветке B , ветвь B меняет имя на last_name, ветвь A меняет инициалы на first_name. Вы объединяете ветвь A, вы не объединяете ветвь B, потому что она имеет некоторые сложности =› сгенерированная схема содержит имя и фамилию, в то время как вы бы предпочли иметь имя и имя. Некоторая логика может быть полезной для проверки миграций не в master и их отката в schema.rb - person Vikko; 15.05.2013
comment
На первый взгляд это звучит хорошо, но некоторые миграции могут быть не такими обратимыми. Возможно, вы могли бы сделать это вручную с помощью: rake db:migrate VERSION=123, где 123 — номер миграции в вашем schema.rb. Это должно мигрировать либо вперед, либо назад по мере необходимости, чтобы добраться до этой версии. В конечном счете, вам лучше всего будет как можно скорее объединить миграции из каждой ветки в master, даже если вам придется делать это путем выбора вишни. - person sockmonk; 16.05.2013
comment
Я знаю об этом, но проблема связана с работой примерно с 20 ветками, каждая из которых имеет время жизни от нескольких часов до нескольких месяцев. Вот где возникают сложности: вы забываете, что в ветке были миграции, и вы облажались! Кроме того, миграция в большой таблице (более 100 000 записей) занимает много времени. Вы бы предпочли оставить их там для разработки и обновить только схему, если таблица не используется в вашей текущей ветке. - person Vikko; 16.05.2013

arrow_upward
1
arrow_downward

Fresh Temporary DB как быстрый обходной путь

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

  1. git checkout -- db/schema.rb
  2. переключиться на другую базу данных разработки, т.е. обновить config/database.yml
  3. rake db:drop && rake db:setup
  4. грабли базы данных: миграция
  5. зафиксируйте свой красивый db/schema.rb
  6. отменить изменения в config/database.yaml
person wik    schedule 11.05.2015