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

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

Я внедрял EF Migrations в существующий проект, созданный как Code First, на основе статьи Ладислав Мрнка

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

Причина, по которой я сбит с толку, заключается в том, что к идентификатору 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          |
+------------------------------------+-------------------------+------------------------------------------------------------------+----------------+

asp.net-mvc-3 entity-framework-migrations ef-code-first entity-framework-4.3
person bPratik    schedule 05.03.2012    source источник
comment
Как именно вы добились того, что временные метки в базе данных prod и dev различаются? Используете ли вы инициализатор базы данных для обновления БД?   -  person Ladislav Mrnka    schedule 06.03.2012
comment
Первоначально, после включения миграции в стабильной сборке, я запустил update-database, чтобы создать таблицу миграции с записью 00_bootstrap. Теперь я изменил модель и запустил Update-Database -Script для создания скрипта для рабочей БД, а затем Update-Database для переноса Dev DB. Теперь выполнение sql, сгенерированного на предыдущем шаге в БД Prod, создает запись в таблице MigrationsHistory как TIMESTAMP01_AutomaticMigration, тогда как более поздняя команда в БД Dev вставила запись в БД Dev с другой меткой времени, поскольку 2 команды были запущены несколько раз. мгновения друг от друга.   -  person bPratik    schedule 06.03.2012

Ответы (1)


arrow_upward
3
arrow_downward

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

Update-Database -Script

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

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

person Ladislav Mrnka    schedule 06.03.2012
comment
Ах, да, такой же скриптовый подход имеет смысл! вчера я углубился в Add-Migration, а также создал правильные сценарии изменений в виде файлов c # с блоками вверх и вниз. (блоги .msdn.com/b/adonet/archive/2012/02/09/). Однако большое спасибо за ваше понимание! - person bPratik; 06.03.2012