Это хорошая идея для очистки старых файлов миграции Rails?

Ответ 1

Они относительно малы, поэтому я бы решил сохранить их, только для записи.

Вы должны написать свои миграции без ссылок на модели или другие части приложения, потому что они вернутся к вам, преследуя;)

Ознакомьтесь с этими рекомендациями:

http://guides.rubyonrails.org/migrations.html#using-models-in-your-migrations

Ответ 2

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

Ответ 3

Rails 4 Way страница 177: Себастьян говорит...

Малоизвестный факт заключается в том, что вы можете удалить старые файлы миграции (в то время как все еще сохраняя новые), чтобы сохранить папку db/migrateуправляемый размер. Вы можете переместить старые миграции в db/archived_migrations или что-то в этом роде. Как только вы обрезаете размер вашей папки миграции, используйте задачу rake db:reset для (повторно) создать свою базу данных из db/schema.rb и загрузить семена в вашей текущей среды.

Ответ 4

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

Ответ 5

Иногда я очищаю все миграции, которые уже были применены в производстве, и я вижу по крайней мере 2 причины для этого:

• Более управляемая папка. Легче определить, добавлена ​​ли новая миграция.
• Результаты поиска чистого текста (глобальный текстовый поиск в рамках проекта не приводит к количеству бесполезных совпадений из-за старой миграции, скажем, когда кто-то создал какую-то колонку 3 года назад).

Ответ 6

Лично мне нравится поддерживать порядок вещей в файлах миграции. Я думаю, что как только вы вложите все свои изменения в prod, вы должны действительно посмотреть на архивирование миграции. Единственная трудность, с которой я столкнулся, заключается в том, что при запуске Travis он выполняет db:migrate, поэтому это шаги, которые я использовал:

• Переместить исторические миграции с /db/migrate/ на /db/archive/release-x.y/

• Создайте новый файл миграции вручную, используя номер версии из последней миграции запуска в каталоге /db/archive/release-x.y и измените описание на что-то вроде from_previous_version. Использование старого номера версии означает, что оно не будет работать на вашей машине и запутаться.

• Скопируйте содержимое schema.rb изнутри раздела ActiveRecord::Schema.define(version: 20141010044951) do и вставьте в метод change вашего from_previous_version журнала изменений

• Проверьте все это, и Роберт должен быть вашим родительским братом.

Единственное другое соображение было бы, если ваши миграции создадут какие-либо данные (мои тестовые сценарии содержат все свои собственные данные, поэтому у меня нет этой проблемы)

Ответ 7

См. http://edgeguides.rubyonrails.org/active_record_migrations.html#schema-dumping-and-you

Миграции не являются представлением базы данных: либо struct.sql, либо schema.rb. Миграции также не являются хорошим местом для установки/инициализации данных. db/seeds или задача грабли лучше для такого рода задач.

Итак, что такое миграции? По моему мнению, это инструкции по изменению схемы базы данных - либо вперед, либо назад (через откат). Если проблема не возникает, их следует запускать только в следующих случаях:

• На моей локальной машине разработки как способ тестирования самой миграции и записи файла схемы/структуры.
• На компьютерах разработчиков коллег как способ изменения схемы, не отбрасывая базу данных.
• На производственных машинах как способ изменить схему, не отбрасывая базу данных.

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

В средах CI никогда не нужно запускать миграции. Он замедляет работу среды CI и подвержен ошибкам (как говорит руководство Rails). Поскольку тестовые среды имеют только эфемерные данные, вместо этого вы должны использовать rake db:setup, который будет загружаться из schema.rb/structure.sql и полностью игнорировать ваши файлы миграции.

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

С учетом всего сказанного я твердо думаю, что имеет смысл очистить старые миграции по следующим причинам:

• Они могут содержать код, который настолько старый, что он больше не будет работать (например, если вы удалили модель). Это создает ловушку для других разработчиков, которые хотят запустить rake db:migrate.
• Они замедлят grep -подобные задачи и не имеют значения за определенный период.

Почему они неактуальны? Еще раз по двум причинам: история хранится в вашем исходном элементе управления, а фактическая структура базы данных хранится в struct.sql/schema.rb. Мое эмпирическое правило состоит в том, что миграции старше 12 месяцев совершенно неактуальны. Я удаляю их. Если была какая-то причина, по которой я хотел отменить миграцию старше этого, я уверен, что база данных изменилась за это время, чтобы гарантировать новый перенос для выполнения этой задачи.

Итак, как вы избавляетесь от миграций? Это следующие шаги:

• Удалить файлы миграции
• Напишите команду rake для удаления соответствующих строк в таблице schema_migrations вашей базы данных.
• Запустите rake db:migrate, чтобы восстановить структуру .sql/schema.rb.
• Подтвердите, что единственное, что изменилось в struct.sql/schema.rb, - это удалить строки, соответствующие каждой удаленной вами миграции.
• Разверните, затем запустите задачу рейка с шага 2 при выпуске.
• Убедитесь, что другие разработчики запускают команду rake с шага 2 на своих машинах.

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

Ответ 8

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

Так лучше удалить эту ссылку из миграции. И refactore/минимизировать миграцию в один или два файла перед большой версией в живую базу данных.

Ответ 9

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

Некоторые люди будут запускать миграции с нуля, чтобы перезагрузить свою базу данных dev, но это не совсем то, для чего они предназначены. Вы можете использовать rake db:schema:load для загрузки последней схемы и rake db:seed, чтобы заполнить ее семенными данными. rake db:reset делает и для вас. Если у вас есть расширения базы данных, которые нельзя сбрасывать на schema.rb, вы можете использовать формат схемы sql для ActiveRecord и запустить rake db:structure:load вместо этого.

Ответ 10

Я согласен, нет значения в 100+ миграциях, история беспорядок, нет простого способа отслеживания истории в одной таблице, и она добавляет беспорядок в поиск файлов. Просто Muda IMO:)

Здесь приведено трехэтапное руководство по сквоту всех миграций в идентичную схему как production:

Шаг 1: схема производства

# launch rails console in production
stream = StringIO.new
ActiveRecord::SchemaDumper.dump(ActiveRecord::Base.connection, stream); nil
stream.rewind
puts stream.read

Это скопируется для переноса в миграции, минус очевидный заголовок

Шаг 2: создание миграций без его запуска в процессе производства

Это важно. Используйте последнюю миграцию и измените ее имя и содержимое. ActiveRecord хранит номер datetime в таблице schema_migrations, чтобы он знал, что он запустил, а не. Повторное использование последнего, и он подумает, что он уже запущен.

Пример: rename 20161202212203_this_is_the_last_migration -> 20161202212203_schema_of_20161203.rb

И поставьте схему там.

Шаг 3. Проверка и устранение неполадок

Локально, rake db: drop, rake db: create, rake db: migrate

Убедитесь, что схема идентична. Одна из проблем, с которыми мы столкнулись, - это datetime "now()" в схеме, вот лучшее решение, которое я мог бы найти для этого: fooobar.com/info/198217/...