Редактирование существующих миграций Rails — хорошая идея?

Если вы работаете с командой и совершили миграцию, НЕТ.

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

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

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

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

• Живой сайт: на живом сайте вы не можете просто использовать rake: db reset, потому что вам явно нужны все эти данные.
• В сотрудничестве: вам необходимо поддерживать миграцию в соответствии с другими разработчиками. Что, если они ввели данные в свою базу данных (для какой-либо цели) и просто смешали ваш код. Теперь вы полностью сорвали их усилия, и они будут вынуждены сбросить всю свою базу данных.
• Rake db:rollback : После того, как вы изменили код, вам придется выполнить сброс, теперь вы не можете запустить откат.
• Это плохая привычка: в большинстве случаев вежливым способом сделать это является создание новой миграции. Лучше иметь привычку и склад ума, чтобы иметь возможность быстро и эффективно создавать новые миграции.

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

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

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

Есть одно исключение, и оно сложное, связанное с удалением зависимостей. Одна из проблем, с которыми сталкиваются миграции, в которых участвуют третьи стороны в ORM с ограниченными обстоятельствами, заключается в том, что зависимости представляют собой «или-или». Они либо есть, либо их нет. Поэтому, если в какой-то момент вы добавите зависимость, на которую затем создадите внешние ссылки из своей модели, и сохраните ее в миграции, а затем удалите эту зависимость, когда вы запускаете миграцию с нуля, зависимость, которая связана с в миграции не удастся, потому что цель внешнего ключа просто больше не существует. Это сложная проблема, потому что в этой ситуации вам фактически нужно будет отредактировать старые миграции, чтобы удалить внешние ключи, но вам также необходимо выполнить миграцию для существующих установок, чтобы удалить ключ. Общий шаблон здесь, если ваша система миграции поддерживает сценарии, проверьте, существует ли ключ, а затем, и ТОЛЬКО тогда, удалите ключ, в противном случае пропустите удаление. Имейте в виду, кстати, что структура типа try {}, кроме {} может быть здесь неправильным выбором, потому что некоторые ORM откатывают транзакции, выстроенные для записи, когда возникает исключение любого рода, чтобы избежать повреждения.

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