从文档中提取的PartitionKey与标头中指定的键不匹配 [英] PartitionKey extracted from document doesn't match the one specified in the header

问题描述

我在一个长字段(playerId)上创建了一个分区集合，并且还在该字段(DataType.Number)上添加了哈希索引.当我大多数时候插入记录时，它可以工作，但有时它会给我PartitionKey extracted from document doesn't match the one specified in the header.

I have created a partitioned collection on a long field (playerId) and also added a hash index on that field (DataType.Number). When I insert records most of the time it works, but sometimes it gives me a PartitionKey extracted from document doesn't match the one specified in the header.

在Azure数据资源管理器中对此进行测试之后，我发现长整数存在舍入问题.如果我通过Data Explorer插入183548146777950021，它将保存它，但随后将与183548146777950000相同的记录返回给我.这是一个已知问题吗?

After I tested this in the Azure Data Explorer I found out there's a rounding problem with long numbers. If I insert 183548146777950021 through Data Explorer it will save it, but then return that same record to me as 183548146777950000. Is this a known issue?

我正在Direct/TCP模式下使用最新的1.23.2.NET客户端.

I'm using the latest 1.23.2 of the .NET client, in Direct/TCP mode.

推荐答案

如果我通过数据资源管理器插入183548146777950021，它将保存它，但随后将相同的记录作为183548146777950000返回给我.这是已知问题吗?

If I insert 183548146777950021 through Data Explorer it will save it, but then return that same record to me as 183548146777950000. Is this a known issue?

据我所知，Azure DocumentDB对数字使用IEEE754标准，这可能会导致大整数或精度更高的十进制数字的截断或精度下降.如果可能，您可以尝试将playerId字段修改并存储为字符串"183548146777950021".

As far as I know, Azure DocumentDB uses IEEE754 standard for numbers, which could cause the truncation or loss of precision for large integers or higher precision decimal numbers. If possible, you could try to modify and store the playerId field as string "183548146777950021".

您可以参考以下类似问题: Azure DocumentDB十进制截断.

And you could refer to this similar issue: Azure DocumentDB decimal truncation.

这篇关于从文档中提取的PartitionKey与标头中指定的键不匹配的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！