Эта страница (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' или PartitionKey e q '41' "): 0 объектов
Учитывая ограничение в 15 сравнений, я ожидал, что этот фильтр $ вызовет сбой запроса.
В случае, если мне нужно было интерпретировать «15 дискретных сравнений» определенным образом, я попробовал этот запрос с различными и / или комбинациями. Это всегда удается.
Связано ли это ограничение с предыдущим поколением API таблиц Azure, которого больше не существует?
Есть ли другие ограничения на $ filter? Например, максимальная длина строки?
Спасибо
** РЕДАКТИРОВАТЬ **
Я еще немного поэкспериментировал с этим. Если предположить, что Эмулятор хранения разработки такой же, как и реальная служба, количество операторов сравнения, которые можно использовать в запросе, не является фиксированным. Вот некоторые результаты экспериментов, которые дали успешные результаты, когда приращение на единицу приводит к ошибке:
(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 Too Long.
Таким образом, все те случайные результаты, которые я получил от эмулятора хранилища, по-видимому, не относятся к живому сервису. А еще лимит в 15 сравнений больше не существует? (предположение)
Методом проб и ошибок похоже, что я начинаю получать ошибку 414, когда полный URI составляет около 32768 (32 КБ) символов. Это полностью закодированный URL-адрес, включающий все остальные параметры, схему, имя хоста и т. Д. Я не думаю, что есть надежный способ предварительно вычислить точную длину URI, которая будет создана ExecuteQuery, поэтому я полагаю, что можно просто разделить запрос, начиная после примерно 32500 символов $ filter строки? И тогда не ожидайте, что он будет работать с эмулятором хранилища ...
