docModel.Property( d= d.Tags).HasConversion( t= ToJson(t),t= FromJsonList string(t));结果文件看起来是这样的: { "tags": "[\"one\ ", \"two\ ", \"three\ "]" } 在EF Core 6.0中 ， 我只是删除...

docModel.Property( d=> d.Tags).HasConversion( t=> ToJson(t),t=> FromJson<List< string>>(t));结果文件看起来是这样的:

{ "tags": "[\"one\ ", \"two\ ", \"three\ "]" } 在EF Core 6.0中 ， 我只是删除了代码然后利用原始类型的内置处理方式 ， 结果是这样的文档:

{ "tags": ["one","two","three" ] }【EF Core 6.0 Azure Cosmos DB Provider的新特性】这导致了schema发现改变 ， 但是Azure Cosmos DB没有问题处理 。 另一方面 ， 当使用标签作为数组的当前模型遇到使用标签作为字段的旧记录时 ， c#代码将抛出异常 。 当EF Core没有NoSQL迁移的概念时 ， 我们如何处理这个问题?
Raw SQL
一个很常见的请求是允许开发人员为数据访问编写自己的SQL 。 这正是我处理代码迁移所需要的特性 。 要使Raw SQL工作 ， 它必须投射到一个现有的模型 。 它是实体的DbSet<T>的扩展 。 在我的例子中 ， 它支持就地迁移 。 在更新代码之后 ， 尝试加载文档将会失败 。 文档只有一个字符串属性用于“tag” ， 但c#模型是一个数组 ， 因此JSON序列化会抛出一个异常 。 为了解决这个问题 ， 我使用了Azure Cosmos DB的一个内置特性 ， 它将 字符串解析为数组 。 使用查询 ， 我将实体投影到匹配当前schema的文档中 ， 然后将其保存回来 。 这是迁移代码:

vardocs = awaitDocuments.FromSqlRaw("select c.id, c.Uid, c.AuthorAlias, c.Deion, c.Html, c.Markdown, c.PublishDate, c.Title, STRINGTOARRAY(c.Tags) as Tags from c").ToListAsync;foreach( vardoc indocs){ Entry(doc).State = EntityState.Modified; } 这个特性使开发人员能够创建LINQ provider可能不支持的复杂查询 。

• 字符串解析为数组： https://docs.microsoft.com/en-us/azure/cosmos-db/sql/sql-query-stringtoarray

其他增强功能
除了我已经介绍过的内容之外 ， 这些增强功能也包含在其中 。

• 对于多对多关系 ， EF Core现在 隐式地在连接类型上使用分区键。
• 您可以在实例、类型和集合级别为 文档配置生存时间(TTL)。
• 您可以 配置容器特性， 如吞吐量、大小等 通过EF Core APIs 。
• 我们现在记录特定于Cosmos DB的 诊断事件， 包括查询成本 。
• 我们在查询中添加了对DISTINCT操作符的 支持。
• LINQ provider现在将某些方法(如字符串操作和数学操作)转换为它们的原生Cosmos DB 对应方法。

• 隐式地在连接类型上使用分区键： https://github.com/dotnet/efcore/issues/23491
• 文档配置生存时间(TTL)： https://github.com/dotnet/efcore/issues/17307
• 配置容器特性： https://github.com/dotnet/efcore/issues/17301
• 诊断事件： https://github.com/dotnet/efcore/issues/17298
• 支持： https://github.com/dotnet/efcore/issues/16144
• 对应方法： https://github.com/dotnet/efcore/issues/16143

总结

文章图片


文章图片

我对即将到来的变化感到兴奋 ， 希望你们也一样 。 你正在使用Cosmos DB provider吗? 如果还没有 ， 在我们添加了以上功能之后你愿意使用吗? 或者还有更多需求和建议 ， 请在本文下面留言 ， 谢谢！
开始使用EF Core和Azure Cosmos DB