Внедрение контекста EF в ASP.NET Основное приложение и использование миграций

#c# #asp.net-core

#c# #asp.net-core

Вопрос:

В настоящее время я пытаюсь использовать dbcontext EF Core с cosmos db на .NET Core 2.2. В моем startup cs настройка внедрения контекста db выглядит следующим образом:

 var configBuilder= new ConfigurationBuilder()
    .SetBasePath(Directory.GetCurrentDirectory())
    .AddJsonFile("appsettings.json");

IConfigurationRoot config = configBuilder.Build();

IConfigurationSection configSection = config.GetSection("CosmosSettings");

services.AddDbContext<PiServeDb>(options => options.UseCosmosSql(
    configSection["ServiceEndpoint"], configSection["AuthKey"], configSection["DatabaseName"]
));
  

С помощью конфигурационных данных cosmosdb в appsettings.json файле.

DbContext Это настройка, позволяющая DbContextOptions вот так:

 public class PiServeDb : DbContext
{
    public PiServeDb(DbContextOptions<PiServeDb> options)
    : base(options){ }

    public DbSet<Device> Devices { get; set; }
}
  

и при попытке запустить начальную миграцию для обновления базы данных я постоянно получаю эту ошибку:

Не удается разрешить службу для типа ‘Microsoft.EntityFrameworkCore.Миграции.IMigrator’. Часто это происходит потому, что ни один поставщик базы данных не был настроен для этого DbContext. Поставщик может быть настроен путем переопределения DbContext.Методом OnConfiguring или с помощью AddDbContext у поставщика услуг приложения. Если используется AddDbContext, то также убедитесь, что ваш тип DbContext принимает объект DbContextOptions в своем конструкторе и передает его базовому конструктору для DbContext.

Я настроил класс так, чтобы он принимал это в конструкторе, поэтому я понятия не имею, что я сделал не так. Что-то не так с моей настройкой?

Комментарии:

1. Вы добавили следующий пакет Microsoft.EntityFrameworkCore.Cosmos ? Также я думал, что у Cosmos нет схемы, так как бы вы перенесли структуру схемы в не schema?

2. В Cosmos DB нет миграций Миграции создаются для реляционных баз данных. Однако Cosmos DB не имеет схемы на уровне базы данных, поэтому ей не нужны миграции

3. Однако работа с поставщиком не завершена , и важные функции, такие как обработка отсутствующих свойств , еще не реализованы.

4. @MasonTurvey нет необходимости это делать. Вам не нужны миграции в базе данных без схемы. Вы можете просто писать новые объекты с новыми свойствами без каких-либо изменений. Проблема с «пропущенными свойствами» связана с тем, как поставщик будет обрабатывать отсутствующие свойства — представьте, что вы пытаетесь десериализовать строку JSON, которая не имеет всех атрибутов вашей сущности. Что вы делаете? Вы можете оставить их пустыми или отклонить. Или вы можете каким-то образом проверить строку, чтобы определить, какую версию объекта вам следует использовать

5. @MasonTurvey кстати, это ничем не отличается от MongoDB или RavenDB — создателю и читателю документа не нужно использовать одну и ту же схему.

Ответ №1:

CosmosDB не содержит схемы. Как таковое, понятия «миграции» не существует. Если вы добавляете новое свойство, оно просто начинает сохранять данные для этого нового свойства. Конечно, есть определенные сценарии, в которых вы хотели бы «перенести» — возможно, вы переименовали prop. Однако это скорее перенос данных. Все элементы в вашем контейнере необходимо будет обновить, чтобы переместить данные из старого элемента в новый элемент. EF Core в настоящее время не поддерживает сценарии такого типа, поэтому вам нужно будет разработать собственную стратегию для внесения таких изменений.

Короче говоря, вы не создаете миграции для хранилища CosmosDB, так что, вероятно, именно поэтому это не работает.

Комментарии:

1. Хотя работа над обработкой отсутствующих свойств все еще продолжается

2. Таким образом, любое переназначение базы данных должно быть выполнено на стороне cosmos и не может быть выполнено через EF core?

3. @MasonTurvey переназначение персонала не требуется. Вы можете изменить свою модель любым удобным для вас способом и начать писать новые документы. Прямо сейчас у вас возникнут проблемы, если вы попытаетесь прочитать новые свойства из старых документов, в которых их нет.

4. Некоторые вещи, которые будут связаны с изменением схемы в реляционном хранилище, да, придется обрабатывать вручную — не все. Тем не менее, вы должны понимать, что CosmosDB — это принципиально иная вещь, чем что-то вроде SQL Server. Ядро EF обеспечивает уровень абстракции, но между поставщиками нет 100% поддержки «1 к 1». Поставщик в памяти, например, также не поддерживает многое из того, что делает поставщик SQL Server. Миграции предназначены для реляционных хранилищ, а не для хранилищ документов NoSQL.