Это хорошая идея, чтобы разрушить миграцию старых рельсов?

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

Существуют ли какие-либо недостатки для свертывания миграций 1-35 в одну миграцию? Я планировал сделать это, выполнив первую миграцию для схемы, как сейчас, и удалив все предыдущие миграции.

В настоящее время я единственный человек, работающий над этим проектом, если это имеет значение.

Ответ 1

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

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

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

Ответ 2

Я буду держать их вокруг. Не беспокойтесь о том, чтобы запускать множество миграций каждый раз, когда новый разработчик проверяет проект. Он всегда может запускать

rake db:schema:load

который намного быстрее, вместо запуска

rake db:migrate

Ответ 3

Иногда миграции могут использовать модели, которые больше не существуют или создают таблицы, а затем уничтожают их, тратя драгоценное процессорное время. Лучше всего скомпилировать его в db/schema.rb и заставить разработчиков запускать rake db:schema:load

Ответ 4

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

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

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

В обзоре - я повторяю уже сделанные точки. rake db:migrate VERSION -1

[Я обвиняю отвлекающий новый анимированный логотип, чтобы отвести взгляд от текста]

Ответ 5

Нет вреда, а свертывающиеся миграции - это хорошая практика и помогает повысить производительность при выполнении миграций. Теперь это часть схемы schema.rb:

# Note that this schema.rb definition is the authoritative source for your
# database schema. If you need to create the application database on another
# system, you should be using db:schema:load, not running all the migrations
# from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).

Обратите внимание, что @mike-woodhouse говорит: "Будьте предупреждены, что если у вас есть операции манипуляции данными в ваших существующих миграциях, например, статические нагрузки данных и/или возможные последующие преобразования, тогда их нужно будет обрабатывать где-то".

Но вы ни в коем случае не должны делать ничего из своих миграций:) - Чад

Ответ 6

Для тех, кто, как и я, нашел этот ответ в поисках способа вернуть reset приложение в исходное состояние, вот что делать:

rm db/migrations/*
rake db:drop
rake db:schmea:dump

Это полезно, если вы только что запустили приложение и решили пересоздать его с нуля, не потеряв все ваши файлы.