Я имел в виду, что при запуске миграции данные базы данных обновляются, делается снимок, и в результате получается синхронизированная система:
- данные базы данных выглядят как X
- ContextModelSnapshot выглядит как X
Позже я могу либо обновить данные в базе данных, либо обновить данные в снимке, а затем, в зависимости от того, что я сделал, я могу сказать EFCoreМигратор может либо:
- обновить базу данных (если я отредактировал снимок) и сгенерировать обновление в стиле sql / fluent базы данных базы данных, чтобы база данных снова синхронизировалась со снимком => с помощьютаблица БД как «что было» и снимок как «что будет»
- обновить снимок (если я обновил БД) и снова сгенерировать некоторые sql / fluent обновления стиля для синхронизации двух, но на этот разиспользуя снимок в качестве ссылки на «что было» и базу данных в качестве ссылки на «что должно быть»
В любом случае можно создать миграцию, и я просто говорю EF, который является авторомо том, какими должны быть данные
Перейдем к созданию моей миграции;Я фактически продвинул один БД по отношению к другому БД, и снимок не синхронизировался ни с одним из них благодаря другой миграции, которая была применена в другом месте, но я не был привязан к ней.Поэтому вместо этого я написал SQL-код, который генерировал бы выглядящий моментально код (строки concat вместе для создания кода на c #) из базы данных «what was», и поместил вручную созданный код в снимок, а затем попросил EF выполнить миграцию (с помощью «whatбыть "БД настроена в настройках приложения)
Сгенерировано то, что я ожидал;некоторые запросы на обновление .. Но в основном он генерирует вставки для данных, которые уже существовали, поэтому теперь я получаю нарушения PK.Таким образом, я полагаю, что полностью ошибаюсь из-за того, как мигратор работает внутри.Если бы я находился в ситуации, когда единственными ориентирами для того, как я хотел, чтобы моя миграция БД шла, были две БД (одна рабочая, одна моя разработчик), как бы мне было создать миграцию, если бы ядро ef было не синхронизировано с обоими