Соглашения об именах для первых переходов кода

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

Каким образом можно перейти к вызовам этих миграций? Примеры всегда смехотворно упрощены: например, добавление свойства Readers приводит к миграции AddReaders.

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

Ответ 1

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

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

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

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

Когда вы работаете с небольшими единицами изменения, слияние и разрешение конфликтов становится намного проще.

Ответ 2

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