0

我正在尝试使用 Cosmos DB 表。我注意到的是，如果我查询Timestamp属性，则不会返回任何数据。

这是我正在使用的查询：

Timestamp ge datetime'2010-01-01T00:00:00'

我相信我的查询是正确的，因为相同的查询在我的存储帐户中的表上运行得非常好。

如果我查询任何其他属性，查询运行得非常好。

我尝试在 Cerebrata Cerulean 和 Microsoft Storage Explorer 中运行此查询，但在这两个地方都没有得到任何结果。

但是，当我在 Azure 门户数据资源管理器中运行相同的查询时，会返回数据。我在 Azure 门户中打开了开发人员工具，发现门户没有进行 OData 查询。相反，它正在进行 SQL API 查询。例如，在上述情况下，正在发送的查询是：

Select * from c where c._ts > [epoch value indicating time]

同样，如果我使用上述工具查询属性：

AttributeName eq 'Some Attribute Value'

在 Azure 门户中发送相同的查询

SELECT * FROM c WHERE  c.AttributeName["$v"] = 'Some Attribute Value'

所有文档都指出我应该能够编写 OData 查询并且它们应该可以工作，但我认为它不正确。

那么查询 Cosmos DB 表的正确方法是什么？

更新

似乎这不仅仅是Timestamp属性的问题，而是所有Edm.DateTime类型的属性。

更新#2

因此，我将我的 Cosmos DB 表帐户作为 SQL API 帐户打开，以查看数据实际上是如何存储在后台的。

我观察到的第一件事是Timestamp财产根本没有被存储。（在存储表实体中）的值Timestamp实际上被存储为_ts系统属性，也被存储为Epoch秒。

接下来我注意到的是，所有日期/时间类型的属性实际上都被转换为 20 个字符长的字符串，并存储如下：

"SourceTimestamp": {
    "$t": 9,
    "$v": "00637219463290953744"
},

我想知道这是否与无法直接发出 ODATA 查询有关。

顺便说一句，我忘了提到我正在使用 Azure Storage Node SDK 来访问我的 Cosmos Table 帐户（因为这是微软推荐的，因为没有专门用于 Table API 的 Node SDK）。

4

1 回答 1

1

感谢您在我调查此问题时的耐心等待。

此行为的根本原因是，虽然 Storage 表存储具有刻度的时间粒度，但 Cosmos DB 的 _ts 处于第二级粒度。这与 OData 无关。我们实际上阻止了对时间戳属性的查询，因为它使客户感到困惑，并且不建议对存储表进行整体基于时间戳的查询。

解决方法是添加您自己的自定义日期时间或长数据类型属性，并自己从客户端设置值。

我们将在未来的更新中解决这个问题，但目前尚未安排这项工作。

谢谢。

于 2020-04-29T17:23:03.167 回答