azure-table-storage - Azure表查询中的最大$ filter比较

Question

此页面(https://docs.microsoft.com/en-us/rest/api/storageservices/querying-tables-and-entities)说:

Note that no more than 15 discrete comparisons are permitted within a $filter string.

但是，在我的实验中，我已经达到了这个极限，并且没有任何副作用。例如，这来自Azure存储资源管理器:

Statistics for storageacct/table ("PartitionKey eq '1' or PartitionKey eq '2' or PartitionKey eq '3' or PartitionKey eq '4' or PartitionKey eq '5' or PartitionKey eq '6' or PartitionKey eq '7' or PartitionKey eq '8' or PartitionKey eq '9' or PartitionKey eq '10' or PartitionKey eq '11' or PartitionKey eq '12' or PartitionKey eq '13' or PartitionKey eq '14' or PartitionKey eq '15' or PartitionKey eq '16' or PartitionKey eq '17' or PartitionKey eq '18' or PartitionKey eq '19' or PartitionKey eq '20' or PartitionKey eq '21' or PartitionKey eq '22' or PartitionKey eq '23' or PartitionKey eq '24' or PartitionKey eq '25' or PartitionKey eq '26' or PartitionKey eq '27' or PartitionKey eq '28' or PartitionKey eq '29' or PartitionKey eq '30' or PartitionKey eq '31' or PartitionKey eq '32' or PartitionKey eq '33' or PartitionKey eq '34' or PartitionKey eq '35' or PartitionKey eq '36' or PartitionKey eq '37' or PartitionKey eq '38' or PartitionKey eq '39' or PartitionKey eq '40' or PartitionKey eq '41'"): 0 entities

给定15个比较限制，我希望这个$ filter导致请求失败。

在需要以某种方式解释“15个离散比较”的情况下，我尝试了使用各种和/或组合的查询。它总是成功。

此限制是否来自不再存在的上一代Azure Table API？

$ filter还有其他限制吗？如最大字符串长度？

谢谢

** 编辑 **

我已经对此进行了更多的实验。假设Development Storage Emulator与真实服务相同，则查询中可以使用的比较运算符的数量不是固定的。以下是一些提供了成功结果的实验​​结果，当将结果加一会导致错误:

(PK == V)和((RK == V)或(RK == V)... 97x)//98个比较，97个非PK比较
(PK == V和RK == V)或(PK == V和RK == V)... 97x//194个比较，97个非PK比较
(RK == V)或(RK == V)... 98x//98个比较，98个非PK比较
(PK == V)或(PK == V)... 98x//98个比较，0个非PK比较
(PK == V且RK == V且Prop = V)或(PK == V且RK == V且Prop = V)... 93x//279个比较，186个非PK比较

我不确定从中得出什么结论。我可以安全地执行(PK == V和RK == V)或执行97次，但我可以安全地执行(RK == V)或执行98次。我已经用相同的值和不同的值以及其他比较运算符(而不是相等的)对此进行了测试。

有了这些结果，如何可以预知服务器将基于查询字符串返回错误？

15号在哪里发挥作用？

** 编辑 **

我只是在一个实时存储帐户上尝试了所有测试，发现没有最大值。实际上，我一直能够成功添加运算符，直到它开始返回为止:

远程服务器返回错误:(414)请求URI太长。

因此，我从存储仿真器获得的所有随机结果显然不适用于实时服务。而且15个比较限制根本不存在了吗？ (推测)

经过反复试验，当完整URI的长度约为32768(32KB)个字符时，我似乎开始出现414错误。那是一个完全编码的URL，包括所有其他参数，方案，主机名等。我认为没有一种可靠的方法可以预先计算ExecuteQuery会产生的确切URI长度，因此我想可以将请求拆分为在大约32500个字符的$ filter字符串之后？然后不要指望它可以与存储模拟器一起使用...

Answer 1

我还使用REST API和客户端库对其进行了测试。我还发现不存在15个离散比较限制。我可以添加很多比较，直到达到URL长度限制。这是我测试过的。

表REST API，PK的1000多个比较。

表REST API，使用不同列进行1000多次比较。

表客户端库，PK的1000多个比较。

表客户端库，使用不同的列进行1000多个比较。

在Azure Table Client Library文档上，我没有找到15个离散比较限制。该限制可能已过时。
Table​Query.​Filter​String Property

您可以在以下文档中发表评论，以获得文档所有者的正式回复。

Querying Tables and Entities