Сравнение фильтра Max $ в запросе таблицы Azure

На этой странице ( https://docs.microsoft.com/en-us/rest/api/storageservices/querying-tables-and-entities) говорится:

Обратите внимание, что в строке $filter разрешено не более 15 дискретных сравнений.

Однако в моих экспериментах я достиг этого предела и не имел никаких побочных эффектов. Например, это из Azure Storage Explorer:

Статистика для storageacct / table ("PartitionKey eq '1" или PartitionKey eq' 2 'или PartitionKey eq' 3 'или PartitionKey eq' 4 'или PartitionKey eq' 5 'или PartitionKey eq' 6 'или PartitionKey eq' 7 'или PartitionKey '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 33'или PartitionKey eq '34', или PartitionKey eq '35', или PartitionKey eq '36', или PartitionKey eq '37', или PartitionKey eq '38', или PartitionKey eq '39', или PartitionKey eq '40', или PartitionKey eq '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 символов? И потом не ожидайте, что он будет работать с эмулятором хранилища...

Источник

1 ответ

Решение

Я также проверил это с REST API и клиентской библиотекой. Я также обнаружил, что предел 15 дискретных сравнений не существует. Я могу добавить множество сравнений, пока не достигну предела длины URL. Вот что я проверял.

  1. Таблица REST API, 1000+ сравнений ПК.
  2. Таблица REST API, 1000+ сравнений с разными столбцами.
  3. Таблица клиентской библиотеки, 1000+ сравнений ПК.
  4. Таблица клиентской библиотеки, 1000+ сравнений с разными столбцами.

В документе клиентской библиотеки таблиц Azure я не нашел 15 дискретных пределов сравнения. Предел может быть устаревшим. Table Query. Filter String Свойство

Вы можете оставить комментарий к следующему документу, чтобы получить официальный ответ от владельца документа.

Опрос таблиц и сущностей

Источник

Я просто хотел повторить то, что наблюдали другие.

Кажется, не существует 15 сравнительных ограничений.

Создание высокопроизводительного приложения на табличном хранилище требует как можно меньшего количества обращений к службе, что означает отправку серверу как можно большего объема работы за один запрос.

Жаль, что истинные ограничения нигде не публикуются и что одно ограничение, которое я нашел (15 сравнений), на самом деле не является ограничением.

В моем тестировании я заметил:

  • 32684 длина URL дает 200 хорошо
  • 32 685 URL-адреса дает 414 URL слишком долго
  • Каждое сравнение ключей строк, отправленное для известных ключей, было учтено и дало результат в ответе HTTP. Никаких ограничений не наблюдалось.
Источник

Я связался с соответствующей группой продуктов Azure и подтвердил, что в коде Azure нет ограничения в 15 элементов. Будет обновлена ​​документация, чтобы отразить это. Извините за путаницу!

Источник
Другие вопросы по тегам