Não só o comportamento esperado está completamente documentado mas também acho sua afirmação falsa. Em uma amostra padrão que possa atender às condições especificadas, os resultados serão os mostrados. Mas primeiro a referência da documentação:
Em seguida, a saída de explicação da consulta válida:
{
"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
}
Portanto, se você deseja emitir consultas que tenham um padrão diferente da "chave composta" que você realmente criou e que atenda às regras claramente especificadas, você também deve ter prestado atenção ao ponto principal:
Portanto, em "qualquer forma" composto ou outro, se você estiver procurando mais de uma definição de um índice de texto do MongoDB, não poderá fazer isso. O mesmo se aplica aos índices "geoespaciais", bem como à consideração geral de que fora de um
$or
expressão ou um .sort()
o mecanismo de consulta pode selecionar apenas um índice por vez. As versões modernas devem relatar a linha muito específica junto com o erro:
Portanto, "todos" os campos são obrigatórios e "devem ser" uma correspondência exata sem o uso de operadores de desigualdade.
Se você não for "sempre" usar os outros campos como parte de sua consulta com condições de "correspondência exata", não poderá formar um índice composto junto com uma pesquisa de texto.
