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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

rake db:schema:load 

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

rake db:migrate 

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

Отсутствие вреда и свертывание миграций является хорошей практикой и помогает повысить производительность при выполнении миграций. Это является частью 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). 

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

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