Oczekiwane zachowanie jest nie tylko w pełni udokumentowane ale uważam również, że twoje twierdzenie jest fałszywe. Na standardowej próbce, która może spełnić określone przez Ciebie warunki, wyniki będą takie, jak pokazano. Ale najpierw odniesienie do dokumentacji:
Następnie wyjaśnij wyjście prawidłowego zapytania:
{
"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
}
Jeśli więc chcesz generować zapytania, które mają inny wzorzec niż „klucz złożony”, który faktycznie utworzyłeś i który spełnia jasno określone reguły, prawdopodobnie powinieneś również zwrócić uwagę na główny punkt:
Tak więc w "dowolnej formie" złożonej lub innej, jeśli szukasz więcej niż jednej definicji indeksu tekstowego MongoDB, nie możesz tego zrobić. To samo dotyczy indeksów „geoprzestrzennych”, a także ogólnego rozważenia, że poza $or
wyrażenie lub .sort()
silnik zapytań może wybrać tylko jeden indeks na raz.
Nowoczesne wersje powinny zgłaszać bardzo konkretną linię wraz z błędem:
Zatem „wszystkie” pola są wymagane i „muszą być” dokładnym dopasowaniem bez użycia operatorów nierówności.
Jeśli nie zamierzasz „zawsze” używać innych pól jako części zapytania z warunkami „dokładnego dopasowania”, nie możesz utworzyć indeksu złożonego wraz z wyszukiwaniem tekstowym.
