Операция Azure CosmosDB не поддерживается при использовании $ elemMatch и $ in

Я выполняю следующий запрос, который отлично работает с MongoDB, но иногда не работает с CosmosDB. Мне он нужен для работы с обоими.

(XXX является заполнителем для любого строкового значения. Все строки имеют уникальные значения, которые отредактированы для удобства чтения, и фактическое содержимое не должно иметь значения.)

{
  server_index: {
    $elemMatch: {
      server: "XXX",
      index: "XXX",
      delete_time: { $exists: false },
      path: {
        $in: ["XXX", "XXX", "XXX" ]
      }
    }
  }
}

Схема документа примерно такая:

{
  ...,
  server_index: [
    {
      server: "XXX",
      index: "XXX",
      delete_time: ISODate(...),  // optional
      path: "XXX"
    },
    {...},  // same as above
    ...
  ],
  ...
}

Этот запрос иногда работает должным образом и с CosmosDB, но иногда я также получаю следующий ответ:

{
  _t: "OKMongoResponse",
  ok: 0,
  code: 115,
  errmsg: "Command is not supported",
  $err: "Command is not supported"
}

Что особенно странно, так это то, что запрос, по-видимому, завершается успешно, а ответ, приведенный выше, возвращается «действительным» курсором в качестве первого документа, что затем вызывает «сбой» моего парсера документов.

Я использую устаревший драйвер C ++. Это вообще поддерживается Cosmos DB?

(По словам разработчика, от которого я унаследовал этот проект, это так, и, как всегда, когда вы наследуете проекты, все работало нормально, согласно предыдущему разработчику ... Так что это может быть связано с изменением в Cosmos DB из-за характера моих тестовых данных, или кто знает что ...)

Боковое примечание: в MongoDB есть многоключевой индекс для server_index, который выглядит так:

{
    "server_index.delete_time" : 1,
    "server_index.server" : 1,
    "server_index.index" : 1,
    "server_index.path" : 1
}

Поддерживается ли это вообще в CosmosDB?

РЕДАКТИРОВАТЬ: Попытка добавить этот индекс с помощью Robo 3T молча терпит неудачу, без каких-либо сообщений об ошибке. Индекс просто не добавляется. Отлично!

(Пожалуйста, не спрашивайте о странной схеме базы данных. Это похоже на то, что на то есть причина, и поверьте мне, я тоже хотел бы все это сжечь и заменить чем-то другим ... Я открыт для предложений хотя для альтернативных запросов)


azure-cosmosdb-mongoapi
person Florian Winter    schedule 11.01.2019    source источник
comment
Эти вопросы, вероятно, лучше задать при поддержке CosmosDB. Драйверы MongoDB не тестируются с Cosmos: ожидается, что их API будет правильно имитировать поведение сервера MongoDB. Обратите внимание, что в Cosmos используется другой подход к индексации, и документация Cosmos в настоящее время рекомендует создавать несколько отдельных индексов вместо одного составного индекса. Можете ли вы отредактировать свой вопрос, включив в него пример запроса, который периодически возвращает эту ошибку?   -  person Stennie    schedule 12.01.2019
comment
@Stennie Вопрос в моем вопросе. Только строковые значения отличаются от XXX, и все они отличаются друг от друга. Все строки в верхнем регистре, но это не имеет значения, поскольку проблема не в совпадении, а в ошибке. Мой вопрос в основном сводится к 1) Какая часть моего запроса не поддерживается и 2) Почему я получаю ошибку как часть результата запроса (возвращаемого курсором), а не сам запрос, как и следовало ожидать?   -  person Florian Winter    schedule 14.01.2019
comment
Поскольку проблема носит временный характер и характерна только для CosmosDB, я по-прежнему считаю, что эту проблему лучше всего поднимать в их группе поддержки. Возврат ответа вместо курсора звучит как ошибка, и команда не поддерживается. Ошибка может быть улучшена, чтобы дать подсказку о том, какая команда завершилась ошибкой. Я бы ожидал предсказуемого отказа, если команда не поддерживается.   -  person Stennie    schedule 14.01.2019
comment
@Stennie Я согласен, и я также думаю, что это похоже на ошибку на стороне сервера. Просто нужно второе мнение по этому поводу. Я посмотрю, есть ли какие-либо диагностические данные на стороне сервера, которые могут пролить свет на это и, возможно, вызвать запрос в службу поддержки.   -  person Florian Winter    schedule 16.01.2019

Ответы (1)


arrow_upward
0
arrow_downward

Вероятно, это была проблема на стороне сервера. Во-первых, это казалось неправильным (статус ошибки возвращался как часть результата запроса), и он исчез через пару недель без каких-либо изменений.

person Florian Winter    schedule 11.02.2019