Управление EF Code First Migrations между разработкой и производством - PullRequest
Новая
       42

Управление EF Code First Migrations между разработкой и производством

4 голосов
/ 05 марта 2012

Очень кратко:

Я реализовывал EF Migrations в существующем проекте, построенном как Code First на основе статьи Ladislav Mrnka

При реализации EF Migrations в проекте, который уже находится в производстве, как можно управлять сценариями миграции между обновлениями, примененными к разработке, а затем сценариями, созданными для производства?

Причина, по которой я сбит с толку, заключается в том, что к MigrationId, сгенерированному для каждого сценария, добавлена ​​метка времени.В моих попытках миграции я заметил, что записи, записанные в таблицах __MigrationHistory для dev и prod, были разными, что поднимало вопрос, если БД должна была пройти через несколько модернизаций миграции, то если по какой-либо причине требуется понижение версии, Было бы очень трудно связать точный MigrationId для создания сценариев, используя update-database -script

Очень простой процесс, в котором вы создаете $InitialMigration, который создает таблицу __MigrationHistory.Затем за любыми изменениями вашей Модели следует любой update-database, чтобы получить базу данных Мигрированный .И этот процесс цикличен всякий раз, когда у вас есть логически сгруппированная партия изменений модели.

Просмотр таблицы __MigrationHistory показал 

+------------------------------------+-------------------------+------------------------------------------------------------------+----------------+
|            MigrationId             |        CreatedOn        |                              Model                               | ProductVersion |
+------------------------------------+-------------------------+------------------------------------------------------------------+----------------+
| 000000000000000_BootstrapMigration | 2012-03-01 17:40:39.567 | 0x1F8B08000000400ECBD07601C49...HASH_TRUNCATED...CA7F54A20F50000 | 4.3.1          |
| 201203011745335_AutomaticMigration | 2012-03-01 17:45:33.557 | 0x1F8B08000000400ECBD07601C49...HASH_TRUNCATED...F4AE3681EF50000 | 4.3.1          |
+------------------------------------+-------------------------+------------------------------------------------------------------+----------------+

1 Ответ

3 голосов
/ 06 марта 2012

Согласно вашему комментарию, решение выглядит простым. Если вы хотите иметь одну и ту же метку времени, вы должны использовать Update-Database только один раз, а в вашем случае это означает: 

Update-Database -Script

и выполнение созданного сценария в обеих базах данных.

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

...