应用错误收集

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

请注意，$ filter字符串中不允许超过15次离散比较。

然而，在我的实验中，我达到了这个极限，没有任何副作用。例如，这来自Azure存储资源管理器：

storageacct / table的统计信息（“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'或PartitionKe y eq'41'“）：0个实体

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

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

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

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

由于

**编辑**

我一直在试验这个问题。假设开发存储模拟器与实际服务相同，则可以在查询中使用的比较运算符的数量不是固定数量。以下是一些实验结果，这些结果给出了成功的结果，当递增1时会导致错误：

（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）Request-URI太长。

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

从试验和错误看，当完整URI长度约为32768（32KB）时，我似乎开始收到414错误。这是一个完全编码的URL，包括所有其他参数，方案，主机名等。我不认为有一种可靠的方法来预先计算由ExecuteQuery产生的确切URI长度，所以我想可以分开请求开始在大约一个32500个字符的$ filter字符串之后？然后不要指望它与存储模拟器一起工作......

Azure表格查询中

3 个答案: