#sql-server #asp.net-mvc #azure-web-app-service #azure-sql-database
Вопрос:
Мы используем базу данных SQL Server и веб-приложения, размещенные в Azure. Мы поддерживаем версию базы данных в таблице со столбцом версии.
Мы добавили код для Application_Start() проверки версии базы данных и выполнения команд с более высокой версией, чем текущая из нашей ASP.NET Приложение MVC для обновления схемы.
Это работало нормально, пока недавно мы не заметили, что в течение нескольких секунд Application_Start событие снова запустилось, и функциональность схемы обновления выполнялась дважды.
Как мы можем предотвратить обновление схемы, добавив некоторую проверку, существует ли другая схема обновления экземпляра, или есть способ не запускать Application_Start событие несколько раз?
Мы развертываем код в веб-приложении с помощью конвейера Azure Dev Ops.
Спасибо!
Ответ №1:
Ваше веб-приложение может быть переработано по нескольким причинам, которые находятся вне вашего контроля. Поэтому размещение кода в Application_Start для запуска сценариев, обновляющих вашу базу данных, не является оптимальным по причинам, которые вы только что упомянули.
Поскольку вы уже используете конвейер Dev Ops, существует встроенный способ обработки этого в рамках вашего развертывания. Проверьте тип проекта базы данных в Visual Studio. Это позволит вам создавать сценарии всех ваших таблиц, хранимых процедур, представлений и т.д. В текстовой форме и сохранять их под управлением исходного кода. Затем, как часть конвейера Dev Ops, вы можете использовать задачу сборки Visual Studio для создания проекта базы данных и создания DACPAC в качестве вывода. Затем используйте задачу развертывания базы данных SQL Azure, чтобы получить выходные данные DACPAC и развернуть их в экземпляре SQL Azure.
Таким образом, вы будете ЗНАТЬ, что ваша база данных уже обновлена до завершения рабочего развертывания.
Комментарии:
1. Спасибо тебе, Роб! мы собираемся попробовать это для долгосрочного решения. Пока это не будет сделано, мы добавим уникальное ограничение в столбец номер версии. Таким образом, в случае параллельного выполнения одно из выполнений завершится неудачно при попытке использовать один и тот же номер версии и не вызовет проблем с дублированием записей основных данных.
2. @SushrutParanjape Еще один вариант, который следует рассмотреть, — это миграция EF ( docs.microsoft.com/en-us/ef/core/managing-schemas/migrations/… ) . Это в основном сгенерированный код, который применяется условно. Возможно, в краткосрочной перспективе вы почувствуете себя более комфортно с таким подходом. Но я думаю, что конвейерный подход DevOps превосходен.
3. Спасибо, Роб, за предложение! Мы займемся этим вопросом. На данный момент мы не используем EF в нашем проекте. Требуется ли для этого, чтобы мы внедрили EF в наш проект? Или есть какая-то альтернатива?
4. Я действительно в это верю. На самом деле вам не нужно использовать EF в своем приложении, но я считаю, что вам нужно будет настроить контекст EF и синхронизировать модель EF с базой данных. Если вы еще не используете EF, я думаю, что это будет огромной проблемой.
5. Спасибо тебе, Роб, за твой вклад!