Azure表查询中的最大$ filter比较 [英] Max $filter comparisons in an Azure Table Query

问题描述

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

请注意，$ filter字符串中最多只能进行15个离散比较.

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

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

However in my experiments I have hit that limit and not had any side effects. For example, this is from Azure Storage Explorer:

storageacct/表的统计信息("PartitionKey eq'1'或PartitionKey eq'2'或PartitionKey eq'3'或PartitionKey eq'4'或PartitionKey eq'5'或PartitionKey eq'6'或PartitionKey eq'7 '或PartitionKey eq'8'或PartitionKey eq'9'或PartitionKey eq'10'或PartitionKey eq'11'或PartitionKey eq'12'或PartitionKey eq'13'或PartitionKey eq'14'或PartitionKey eq'15'或PartitionKey eq'16'或PartitionKey eq'17'或PartitionKey eq'18'或PartitionKey eq'19'或PartitionKey eq'20'或PartitionKey eq'21'或PartitionKey eq'22'或PartitionKey eq'23'或PartitionKey eq '24'或PartitionKey eq'25'或PartitionKey eq'26'或PartitionKey eq'27'或PartitionKey eq'28'或PartitionKey eq'29'或PartitionKey eq'30'或PartitionKey eq'31'或PartitionKey eq '32 '或PartitionKey eq'33'或PartitionKey eq'34'或PartitionKey eq'35'或PartitionKey eq'36'或PartitionKey eq'37'或PartitionKey eq'38'或PartitionKey eq'39'或PartitionKey eq'40'或分区科y eq'41'):0个实体

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导致请求失败.

Given the 15 comparison limit, I would expect this $filter to cause the request to fail.

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

In the case I needed to interpret "15 discrete comparisons" a certain way, I tried this query with various and/or combinations. It always succeeds.

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

Is this limitation from a previous generation of Azure Table APIs which does not exist anymore?

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

Are there any other limits on $filter? Such as maximum string length?

谢谢

**编辑**

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

I have been experimenting some more on this. Assuming the Development Storage Emulator is the same as the real service, the number of comparison operators which can be used in a query is not a fixed amount. Here are some experiment results which gave successful results where when incrementing by one results in an error:

(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) and ((RK==V) or (RK==V) ... 97x) // 98 comparisons, 97 non-PK comparisons
(PK==V and RK==V) or (PK==V and RK==V) ... 97x // 194 comparisons, 97 non-PK comparisons
(RK==V) or (RK==V) ... 98x // 98 comparisons, 98 non-PK comparisons
(PK==V) or (PK==V) ... 98x // 98 comparisons, 0 non-PK comparisons
(PK==V and RK==V and Prop=V) or (PK==V and RK==V and Prop=V) ... 93x // 279 comparisons, 186 non-PK comparisons

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

I am not sure what conclusion to draw from this. I can safely do (PK==V and RK==V) or'd 97 times, but I can do (RK==V) or'd 98 times. I have tested this with same values and also distinct values, as well as other comparison operators and not just equals.

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

With these results, how can one predictably know the server will return an error based on a query string?

数字15在哪里起作用?

And where does the number 15 come into play?

**编辑**

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

I just tried all of my tests on a live storage account and found there was no maximum. In fact I was able to keep adding operators successfully until it started returning:

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

The remote server returned an error: (414) Request-URI Too Long.

因此，我从存储模拟器获得的所有随机结果显然不适用于实时服务.而且15个比较限制根本不存在了吗? (猜想)

So all of those random results I got from the storage emulator apparently don't apply to the live service. And also the 15 comparison limit does not exist anymore at all? (conjecture)

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

From trial and error, it looks like I start getting a 414 error when the full URI is about 32768 (32KB) characters long. That is a fully encoded URL including all other parameters, scheme, hostname, etc. I don't think there is a reliable way to precompute the exact URI length which would be produced by ExecuteQuery, so I suppose one could just split the request starting after about a 32500 character $filter string? And then don't expect it to work with the storage emulator...

推荐答案

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

I also tested it with REST API and Client Library. I also found that the 15 discrete comparisons limit does not exist. I can add lots of comparisons until reach the URL length limit. Here were what I tested.

1. 表REST API，PK的1000多个比较.
2. 表REST API，使用不同列进行1000多次比较.
3. 表客户端库，PK的1000多个比较.
4. 表客户端库，具有不同列的1000多个比较.

在Azure Table客户端库文档中，我没有发现15个离散比较的限制.该限制可能已过时. 表查询.过滤器字符串属性

On Azure Table Client Library document, I haven't found the 15 discrete comparisons limit. The limit maybe out of date. Table​Query.​Filter​String Property

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

You could post a comment on following document to get the official response from the document owner.

查询表和实体

这篇关于Azure表查询中的最大$ filter比较的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！