Странные результаты запроса в Azure Cosmos DB

Question

В моей базе данных Azure Cosmos DB есть следующие документы:

{
    "id": "token",
    "User": {
        "UserToken": "token",
        "Email": "test@email.com"
    },
    "_ts": 1541493290
}

Когда я запускаю следующий запрос:

SELECT * FROM root  
WHERE ((root["User"]["UserToken"] = "token")  
OR CONTAINS(root["User"]["Email"], "token"))  
ORDER BY root["_ts"] DESC 

Ничего не возвращается. Но когда я это немного изменю. Например, путем преобразования Email в email:

SELECT * FROM root  
WHERE ((root["User"]["UserToken"] = "token")  
OR CONTAINS(root["User"]["email"], "token"))  
ORDER BY root["_ts"] DESC 

Результат найден. Более того, когда я удаляю предложение ORDER BY, запрос также возвращает мне результат. Таким образом, запрос похож на следующий

SELECT * FROM root  
WHERE ((root["User"]["UserToken"] = "token")  
OR CONTAINS(root["User"]["Email"], "token"))  

Более того, когда я редактирую документ (например, открываю его, добавляю пустую строку и сохраняю), на заднем плане происходит какое-то волшебство, и документ обнаруживается. Для довольно «новых» документов (менее 1-3 месяцев) я могу искать их без своего «волшебного» трюка.

Определение индексов:

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*",
            "indexes": [
                {
                    "kind": "Range",
                    "dataType": "Number",
                    "precision": -1
                },
                {
                    "kind": "Hash",
                    "dataType": "String",
                    "precision": 3
                }
            ]
        }
    ],
    "excludedPaths": []
}

Что я сделал не так?

ОБНОВЛЕНИЕ ответ не является полным объяснением, но очень помогает. Полное объяснение в моем блоге (https://stapp.space/ridiculous-bug-in-azure-cosmos-db/)

Answer 1

CONTAINS(root["User"]["Email"], "token") не будет работать, если у вас есть строки, индексированные как Hash. Они должны быть Range с точностью -1. Хеш работает только для проверок на равенство.

Вот почему строчная работает. Потому что он не может найти свойство и просто игнорирует его, возвращаясь к проверке равенства. Первый находит его, видит, что он не проиндексирован как Range и просто не может его вернуть.

Изменение индексации на это будет работать:

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*",
            "indexes": [
                {
                    "kind": "Range",
                    "dataType": "Number",
                    "precision": -1
                },
                {
                    "kind": "Range",
                    "dataType": "String",
                    "precision": -1
                }
            ]
        }
    ],
    "excludedPaths": []
}

Кстати, поле _ts - не лучший способ упорядочения на основе создания. Это метка времени Unix в секундах, поэтому любые документы, созданные за одну секунду, не будут упорядочены должным образом.