Non solo il comportamento atteso completamente documentato ma trovo anche falsa la tua affermazione. Su un campione standard che potrebbe soddisfare le condizioni specificate, i risultati saranno come mostrato. Ma prima il riferimento alla documentazione:
Quindi spiega l'output di una query valida:
{
"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
}
Quindi, se vuoi inviare query che hanno uno schema diverso dalla "chiave composta" che hai effettivamente creato e che soddisfa le regole chiaramente specificate, dovresti anche prestare attenzione al punto principale:
Quindi in "qualsiasi forma" composta o altro, se stai cercando più di una definizione di un indice di testo MongoDB, non puoi farlo. Lo stesso vale per gli indici "geospaziali", così come la considerazione generale che al di fuori di un $or
espressione o un .sort()
il motore di query può selezionare solo un indice alla volta.
Le versioni moderne dovrebbero riportare la riga molto specifica insieme all'errore:
Quindi "tutti" i campi sono obbligatori e "devono essere" una corrispondenza esatta senza utilizzare operatori di disuguaglianza.
Se non intendi utilizzare "sempre" gli altri campi come parte della tua query con condizioni di "corrispondenza esatta", non puoi formare un indice composto insieme a una ricerca di testo.
