Ikke alene er den forventede adfærd fuldstændig dokumenteret men jeg finder også din påstand forkert. På en standardprøve, der kunne opfylde de betingelser, du angiver, vil resultaterne være som vist. Men først dokumentationsreferencen:
Derefter forklarer output af af gyldig forespørgsel:
{
"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
}
Så hvis du vil udsende forespørgsler, der har et andet mønster end den "sammensatte nøgle", du faktisk har oprettet, og som opfylder de regler, der er klart specificeret, så burde du muligvis også have været opmærksom på hovedpointen:
Så i "enhver form" sammensat eller andet, hvis du søger mere end én definition af et MongoDB-tekstindeks, kan du ikke gøre det. Det samme gælder for "geospatiale" indekser, såvel som den generelle betragtning, at uden for en $or
udtryk eller en .sort()
forespørgselsmotoren kan kun vælge ét indeks ad gangen.
Moderne versioner bør rapportere den meget specifikke linje sammen med fejlen:
Så "alle" felterne er obligatoriske, og de "skal være" et nøjagtigt match uden brug af ulighedsoperatorer.
Hvis du ikke "altid" vil bruge de andre felter som en del af din forespørgsel med "eksakt match"-betingelser, kan du ikke danne et sammensat indeks sammen med en tekstsøgning.