Tidak hanya perilaku yang diharapkan sepenuhnya didokumentasikan tetapi saya juga menemukan pernyataan Anda salah. Pada sampel standar yang dapat memenuhi kondisi yang Anda tentukan, hasilnya akan seperti yang ditunjukkan. Tapi pertama-tama referensi dokumentasi:
Kemudian penjelasan output dari query yang valid:
{
"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
}
Jadi jika Anda ingin mengeluarkan kueri yang memiliki pola berbeda dengan "kunci majemuk" yang sebenarnya telah Anda buat dan yang memenuhi aturan yang ditentukan dengan jelas maka Anda mungkin juga harus memperhatikan poin utama:
Jadi dalam senyawa "bentuk apa pun" atau lainnya, jika Anda mencari lebih dari satu definisi indeks teks MongoDB maka Anda tidak dapat melakukannya. Hal yang sama berlaku untuk indeks "geospasial", serta pertimbangan umum bahwa di luar $or
ekspresi, atau .sort()
mesin kueri hanya dapat memilih satu indeks dalam satu waktu.
Versi modern harus melaporkan baris yang sangat spesifik bersama dengan kesalahan:
Jadi "semua" bidang wajib diisi dan "harus" sama persis tanpa menggunakan operator pertidaksamaan.
Jika Anda tidak akan "selalu" menggunakan bidang lain sebagai bagian dari kueri Anda dengan kondisi "pencocokan persis" maka Anda tidak dapat membentuk indeks gabungan bersama dengan pencarian teks.
