Я работаю над проектом, используя первый код инфраструктуры сущностей 4.3, используя миграции. При запуске локально мой web.config настроен на таргетинг на initializer базы данных, который реализует CreateDatabaseIfNotExists<DataContext>, который вначале запускает мою базу данных разработки тестовыми данными, а также заполняет различные «статические» поисковые данные при первом запуске.Проекты седилизации и ветвления с использованием миграции структуры сущностей
После создания базы данных разработки любые последующие изменения в базе данных выполняются с добавлением миграции в проект и обновлением базы данных с помощью команды PS «updata-database».
Когда я доволен проектом, я разворачиваю код с помощью webdeploy, но копирую базу данных вручную, так как webdeploy не включает таблицу миграции. При развертывании я использую преобразование web.config для установки нового инициализатора базы данных, который реализует MigrateDatabaseToLatestVersion<DataContext>. Затем будут применены новые миграции на основе кода, развернутые впоследствии. Все это работает достаточно хорошо, но у меня есть вопрос, является ли это наилучшим подходом к инициализации моего db не только тестовыми данными, но и данными, необходимыми для запуска приложения. То, что я ищу, - это хороший способ создать исходные данные семени без необходимости подключать его к CreateDatabaseIfNotExists<DataContext>, но вместо этого подключайте его к Migrations. Я понимаю, что в классе конфигурации есть метод семени, но, видя, что он обновляет базу данных при каждой миграции, это нежелательное решение.
Проект находится в TFS, и время от времени мне нужно создать новую ветвь этого проекта, суть которого является клоном первого. При первом запуске этой базы данных база данных еще не существует, но будет создана и засеяна, как объяснялось ранее. Самая большая проблема заключается в том, что изменения схемы, ранее обработанные миграциями, теперь будут применяться, когда база данных будет создана впервые. Если я затем попытаюсь добавить новый файл миграции и запустить «update-database», я столкнулся с стеной, так как он не может запускать предыдущие миграции, потому что эти изменения уже были применены при создании базы данных. Я могу только вообразить, что я делаю что-то неправильно здесь или просто пропустил трюк.
В заключении я ищу информацию о
- Лучшего способа потомству исходных данных тестового & необходимых данные приложений при создании базы данных в первый раз с помощью миграции.
- Лучший способ преодолеть проблемы при ветвлении проекта, содержащего миграцию кода и необходимость создания базы данных в первый раз.
Спасибо за чтение.
Я знаю об упомянутом методе семян. Моя проблема заключается в том, что он выполняется каждый раз, когда выполняется миграция. Некоторые из моих исходных данных ядра были/могут быть изменены через приложение во время его запуска, и я не хочу, чтобы он был сброшен, если добавлена новая миграция. Если у вас есть хороший способ обертывания метода Seed в классе конфигурации, поэтому он выполняется только при миграции InitialCreate, я полагаю, что это сработает, но я не нашел хорошего способа сделать это. – Drauka
Вы несете ответственность за то, чтобы вызов метода «Семя» повторялся - «AddOrUpdate» может помочь с этим. Если вы не можете обеспечить добавление пользовательских семантических предложений SQL непосредственно к вашему методу 'Up' при переносе. –
Я понимаю, о чем вы говорите, но одна из многих причин использовать сущность-структуру заключалась в том, чтобы не писать о том, что может быть относительно сложным оператором вставки SQL. в отличие от посева через контекст. Я работаю над альтернативным решением и опубликую один раз/если проверка работает. – Drauka