Попытка научить себя EF-коду Прежде всего, у вас есть первоначальная настройка создания базы данных, расширенная так, как я ее хочу, и начальное создание базы данных, но пытаюсь понять как лучше всего обрабатывать и управлять будущими обновлениями базы данных и по-прежнему работать с созданием новых баз данных.Код структуры Entity Framework Первые существующие базы данных и новое обслуживание баз данных
Я придумал сценарий, в котором я не нашел никаких хороших примеров или предложений для онлайн. Я хочу, чтобы приложение, которое пользователь мог создать новую базу данных, которая создает новую базу данных на основе существующей модели на основе объектов POCO в коде того времени. Как я уже сказал, это работает для меня до сих пор. Немного позже происходит обновление программы, а через объекты миграции в сборке он знает, что делать и обновляет базу данных, используя сначала миграции EF-кода с использованием метода DbMigrator.Update(). До сих пор хорошо идти, по крайней мере, для начальной версии программы.
Теперь, по очереди, в новой версии, они хотят создать новую базу данных по любой причине. Таким образом, они основываются на текущей модели кода в то время, и это отлично работает. Тем не менее, эти другие миграции происходят до этого момента сборки, которые не нужно запускать вообще, поскольку модель уже имеет какие-либо изменения, которые могут потребоваться для настройки и готовности к работе, но недавно созданная таблица миграции не знайте, что они этого не делают, по крайней мере, насколько я могу судить. Я не хочу, чтобы они запускались, но я хочу, чтобы любые будущие обновления применялись к любой базе данных, которая им нужна в дальнейшем.
Моя мысль, из того, что я читал до сих пор, заключается в том, что мне нужно создать дополнительную логику, чтобы отслеживать, какая последняя миграция БД находится в коде (используя какое-то свойство метки времени для различных миграций, чтобы определить порядок) после создания и как-то сказать, что на самом деле не нужно делать какие-либо обновления миграции, которые существуют до этой даты/версии, но логика миграции EF будет по-прежнему обновлять таблицу __MigrationHistory информацией, которая сообщает ему, что эта конкретная миграция выполнена. Я думаю, что я сделаю это вручную путем отражения, чтобы получить объекты миграции и запустить их в порядке, указав имя объекта миграции в метод обновления, но проверив некоторую проверку, чтобы предотвратить фактическое выполнение изменений базы данных во время инициализации. Затем, когда новые обновления появляются позже после обновления кода, старые миграции не будут выполняться, так как они уже находятся в таблице __MigrationHistory, но метод DbMigrator.Update по-прежнему будет выполнять любые новые миграции, отсутствующие в таблице.
Прежде, чем я потратил много времени на то, чтобы понять эту логику, я хотел убедиться, что в документации нет или что-то в этой трубке, которую я полностью игнорировал или пропустил, и обработал это лучше уже встроенное и/или получить некоторый вклад в лучший способ справиться с этим случаем. По-моему, это довольно распространенный сценарий, но я не вижу в нем хорошего способа обработки его с помощью базовой логики EF.