Azure表查询中的最大$ filter比较

本文介绍了Azure表查询中的最大$ filter比较的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

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

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

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

鉴于比较限制为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...

PK

Azure表查询中的最大$ filter比较

问题描述

推荐答案