Non seulement le comportement attendu est complètement documenté mais je trouve aussi votre affirmation fausse. Sur un échantillon standard qui pourrait répondre aux conditions que vous spécifiez, les résultats seront comme indiqué. Mais d'abord la référence de la documentation :
Ensuite, la sortie d'explication de la requête valide :
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "test.mycollection",
"indexFilterSet" : false,
"parsedQuery" : {
"$and" : [
{
"cid" : {
"$eq" : 2
}
},
{
"uid" : {
"$eq" : 1
}
},
{
"$text" : {
"$search" : "cat",
"$language" : ""
}
}
]
},
"winningPlan" : {
"stage" : "TEXT",
"indexPrefix" : {
"uid" : 1,
"cid" : 2
},
"indexName" : "uid_1_cid_1_content_text",
"parsedTextQuery" : {
}
},
"rejectedPlans" : [ ]
},
"serverInfo" : {
"host" : "trashbox",
"port" : 27017,
"version" : "3.0.0",
"gitVersion" : "a841fd6394365954886924a35076691b4d149168"
},
"ok" : 1
}
Donc, si vous souhaitez émettre des requêtes qui ont un modèle différent de la "clé composée" que vous avez réellement créée et qui respecte les règles clairement spécifiées, vous devriez peut-être également prêter attention au point principal :
Donc, dans "toute forme" composée ou autre, si vous recherchez plus d'une définition d'un index de texte MongoDB, vous ne pouvez pas le faire. Il en va de même pour les index "géospatiaux", ainsi que la considération générale qu'en dehors d'un $or
expression, ou un .sort()
le moteur de requête ne peut sélectionner qu'un seul index à la fois.
Les versions modernes doivent signaler la ligne très spécifique avec l'erreur :
Donc "tous" les champs sont obligatoires et ils "doivent être" une correspondance exacte sans utiliser d'opérateurs d'inégalité.
Si vous n'utilisez pas "toujours" les autres champs dans le cadre de votre requête avec des conditions de "correspondance exacte", vous ne pouvez pas former d'index composé avec une recherche de texte.
