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

Question

Я работаю с большим приложением Rails уже более 2 лет, и изо дня в день моя папка миграции ActiveRecord увеличивается до более чем 150 файлов.приложение, все еще упоминается в миграциях.Я думал удалить их.

Что ты думаешь?Вы обычно удаляете старые миграции из вашей кодовой базы?

Answer 1

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

Answer 2

Рельсы 4 пути стр. 177: Себастьян говорит ...

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

Answer 3

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

1. Более управляемая папка.Проще заметить, если добавлена ​​какая-то новая миграция.
2. Более чистые результаты текстового поиска (Глобальный текстовый поиск в проекте не приводит к множеству бесполезных совпадений из-за старой миграции, скажем, когда кто-то создал какой-то столбец 3лет назад).

Answer 4

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

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

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

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

Answer 5

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 6

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

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

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

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

4. Отметьте все это и Роберт должен быть братом ваших родителей.быть, если ваши миграции создают какие-либо данные (мои тестовые сценарии содержат все свои собственные данные, поэтому у меня нет этой проблемы)

Answer 7

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

Answer 8

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

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

Answer 9

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

Вот трехэтапное руководство по объединению всех миграций в идентичную схему, как production :

Step1:схема из производства

# 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 ()" в схеме, вот лучшее решение, которое я смог найти для этого: https://stackoverflow.com/a/40840867/252799

Answer 10

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

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