EF Core 6操作Cosmos DB(SQL API)是否支持整数分区键？

1. 类型支持差异说明 #

Cosmos DB SQL API 本身原生支持数值、字符串、布尔值作为分区键值，你之前使用原生SDK传入int类型分区键正常读写是符合官方设计的。
你遇到的限制完全来自EF Core 6的Cosmos DB提供程序：该版本的提供程序内部做了硬校验，要求实体上配置的分区键属性必须是字符串类型，或配置了对应的值转换器，不支持直接映射int等非字符串类型的分区键属性，和Cosmos DB本身的能力无关。

2. 整数分区键的变通方案 #

可以直接使用异常提示的值转换器能力，不需要修改实体类上OrganizationId的int类型定义，在OnModelCreating中追加属性转换配置即可：

builder.Entity<QuestionnaireResponse>()
    .ToContainer("QuestionnaireResponses")
    .HasPartitionKey(q => q.OrganizationId)
    // 给int类型分区键配置字符串值转换器
    .Property(q => q.OrganizationId)
    .HasConversion<string>();

配置完成后，EF Core会自动处理写入、查询时的分区键参数绑定，不需要手动调用WithPartitionKey传参，正常编写Where过滤条件q => q.OrganizationId == organizationId即可，EF Core会自动识别分区键值做请求路由，不会再抛出类型校验异常。
如果你的集合中已经存在存量的、分区键为数值类型的文档，使用上述配置后建议做一次存量数据迁移，把旧文档的分区键值统一转为字符串类型，避免出现路由匹配遗漏数据的问题。

3. 字符串类型分区键的可行性与影响 #

直接将分区键存储为字符串是完全合理的生产可用方案，负面影响极低：

• 存储体积：整数转为等长数字字符串仅会增加极少量字节占用，对于绝大多数业务场景，这个体积差异完全可以忽略，不会带来可感知的存储成本上升。
• 读写性能：Cosmos DB对分区键的路由是基于值的哈希计算，字符串和数值类型的哈希计算、匹配性能没有实质差异，不会因为用字符串做分区键就出现写入、查询性能下降。
• 兼容性：字符串类型分区键的扩展性更好，后续如果需要调整分区键规则（比如拼接业务前缀、组合多字段值）不需要修改属性类型，适配性更强。

内容的提问来源于stack exchange，提问作者BenjiFB