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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

rake db:schema:load

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

rake db:migrate

Answer 4

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

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

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

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

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

Answer 5

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

# 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 говорит: «Имейте в виду, что если у вас есть операции манипулирования данными в существующих миграциях, например, статическая загрузка данных и / или возможные последующие преобразования, то их нужно будет где-то обрабатывать».

Но вы все равно не должны делать этого в своих миграциях :) - Чад

Answer 6

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

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

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