Niet alleen is het verwachte gedrag volledig gedocumenteerd maar ik vind je bewering ook onjuist. Op een standaardmonster dat zou kunnen voldoen aan de voorwaarden die u opgeeft, zijn de resultaten zoals weergegeven. Maar eerst de documentatiereferentie:
Dan de uitvoer van een geldige query uitleggen:
{
"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
}
Dus als je queries wilt maken die een ander patroon hebben dan de "samengestelde sleutel" die je daadwerkelijk hebt gemaakt en die voldoen aan de regels die duidelijk zijn gespecificeerd, dan had je misschien ook op het belangrijkste punt moeten letten:
Dus in "elke vorm" samengestelde of andere, als u op zoek bent naar meer dan één definitie van een MongoDB-tekstindex, dan kunt u dat niet doen. Hetzelfde geldt voor "geospatiale" indexen, evenals de algemene overweging dat buiten een $or
expressie, of een .sort()
de query-engine kan slechts één index tegelijk selecteren.
Moderne versies zouden de zeer specifieke regel samen met de fout moeten rapporteren:
Dus "alle" velden zijn verplicht en ze "moeten" exact overeenkomen zonder ongelijkheidsoperatoren te gebruiken.
Als u de andere velden niet "altijd" gaat gebruiken als onderdeel van uw zoekopdracht met "exacte overeenkomst"-voorwaarden, dan kunt u geen samengestelde index vormen samen met een tekstzoekopdracht.