：Perubahan kompatibilitas di MongoDB 3.4

Untuk melihat dokumentasi resmi perubahan kompatibilitas MongoDB, kunjungi Dokumentasi Lama.

Perubahan pada instance kluster sharding

Kompatibilitas penggantian nama koleksi dengan sinkronisasi awal

Jika sebuah koleksi, sebagai sumber sinkronisasi, diganti namanya selama sinkronisasi awal, proses sinkronisasi awal gagal dan dimulai ulang, sehingga menghindari risiko potensi kerusakan data. Untuk informasi lebih lanjut, lihat SERVER-26117.

Operasi berikut mencakup penggantian nama koleksi:

• Perintah renameCollection: seperti metode db.collection.renameCollection().

• Tahap $out dalam operasi agregasi, seperti menggunakan metode db.collection.aggregate() atau perintah aggregate dengan tahap $out.

• Opsi out dalam MapReduce, seperti menggunakan metode db.collection.mapReduce() atau perintah mapReduce dengan opsi out yang ditentukan.

• Perintah convertToCapped yang digunakan untuk mengonversi koleksi biasa menjadi koleksi capped.

Saat Anda meningkatkan dari MongoDB 3.2.11 atau lebih lama ke 3.4, sinkronisasi awal mungkin gagal jika menemui operasi penggantian nama koleksi.

Sebelum MongoDB v3.2.11, proses sinkronisasi awal berlanjut saat menemui operasi penggantian nama koleksi yang dapat merusak data. Untuk informasi lebih lanjut, lihat SERVER-4941.

Operasi yang ditinggalkan

Spesifikasi koleksi dan indeks

db.createCollection( "myCappedCollection", { cappedtypo: true, size: 5242880 } )

Perubahan kompatibilitas umum

• Penyesuaian batas namespace: Mulai MongoDB 3.4, nama database tidak lagi mendukung simbol $.

  Catatan

  Sebelum meningkatkan ke MongoDB 3.4, Anda harus menghapus semua database yang namanya mengandung $.

• Penghapusan parameter textSearchEnabled. Mulai dari MongoDB 2.6, MongoDB mengaktifkan pencarian teks secara default.

• Penghapusan alat mongosniff: Mulai dari MongoDB 3.4, mongosniff digantikan oleh alat mongoreplay yang menyediakan fitur lebih kuat dan mendukung penangkapan dan analisis lalu lintas jaringan yang lebih fleksibel.

• Perubahan perilaku pada tahap agregasi $project: Jika tahap $project menghasilkan dokumen kosong (tidak ada bidang yang dipertahankan atau ditambahkan), kesalahan akan dilaporkan.

• Masalah penghitungan petunjuk dan indeks jarang: Jika Anda menggunakan hint() untuk menentukan indeks jarang saat menghitung dokumen dalam koleksi (dengan predikat kueri kosong), indeks jarang dapat mengakibatkan hasil penghitungan yang tidak akurat.

  db.collection.insert({ _id: 1, y: 1 } );
  db.collection.createIndex( { x: 1 }, { sparse: true } );
  
  db.collection.find().hint( { x: 1 } ).count();

  Untuk mendapatkan hasil penghitungan yang benar, jangan tentukan indeks jarang dalam hint() saat menghitung semua dokumen dalam koleksi.

  db.collection.find().count();
  
  db.collection.createIndex({ y: 1 });
  db.collection.find().hint({ y: 1 }).count();

  Sebelum MongoDB 3.4, petunjuk diabaikan jika penggunaan indeks jarang menyebabkan hasil penghitungan hilang.

Perubahan izin peran pengguna

Mulai dari MongoDB 3.4, izin dari peran bawaan berikut tidak lagi berlaku untuk database local dan config:

Peran bawaan berikut memiliki izin pada database local dan config:

• clusterManager

• clusterMonitor

• backup

• restore

Fitur tidak kompatibel dengan versi selanjutnya

MongoDB 3.4 memperkenalkan fitur berikut yang menyimpan data yang tidak diproses dengan benar oleh versi sebelumnya. Untuk mengaktifkan fitur ini, atur featureCompatibilityVersion ke "3.4".

• Tampilan

• Collation dan indeks case-insensitive

• Tipe desimal

• Versi indeks v2

  • Mendukung collation dan tipe data desimal.

  • Saat featureCompatibilityVersion diatur ke "3.4", versi default indeks baru adalah v2. Jika tidak, versi default adalah v1.

Nilai default untuk featureCompatibilityVersion:

• Penyebaran baru MongoDB 3.4: "3.4".

• Penyebaran yang ditingkatkan dari MongoDB 3.2: "3.2" (perlu diatur secara manual ke "3.4").

Sebelum MongoDB 3.4, jika database berisi tampilan, definisi collation, atau indeks v2, MongoDB tidak dapat dimulai. Jika ada bidang tipe desimal, operasi untuk dokumen-dokumen ini mungkin gagal.

Untuk peningkatan ke MongoDB 3.4, Anda harus membersihkan semua data tidak kompatibel, termasuk tampilan, indeks v2, dan bidang desimal.

Perubahan kompatibilitas driver

Untuk menggunakan fitur baru yang diperkenalkan di MongoDB 3.4 (seperti tipe desimal dan collation), Anda harus meningkatkan driver Anda ke versi yang mendukung fitur-fitur ini.

Perubahan perilaku $in elemen tunggal dan upsert

Ketika operasi upsert tidak menemukan dokumen yang sesuai, ia membuat dokumen dasar untuk upsert berdasarkan pernyataan kesetaraan dalam predikat kueri dan menerapkan operator pembaruan pada dokumen tersebut. Contoh:

db.c.drop()
db.c.update( { a : 3, b: "foo" }, { $set : { c : 15 } }, { upsert : true } )
db.c.find()
{ "_id" : ObjectId("59c03009529946822d0afb8c"), "a" : 3, "b" : "foo", "c" : 15 }

Sebelum MongoDB 3.4, $in elemen tunggal tidak menginisialisasi bidang.

db.c.drop()
db.c.update( { a : { $in : [1] } }, { $addToSet : { a : 2 } }, { upsert : true } )
db.c.find()
{ "_id" : ObjectId("58bdb00eb39e8f87607e9222"), "a" : [ 2 ] }

Mulai MongoDB 3.4, elemen tunggal $in diperlakukan sebagai pernyataan kesetaraan untuk upsert.

• Jika predikat kueri mencakup $in elemen tunggal, bidang diinisialisasi sebagai bidang skalar daripada array.

• Operasi $addToSet dalam contoh sebelumnya gagal karena operator array tidak dapat diterapkan pada bidang skalar.

Solusi: Bungkus ekspresi $in dalam $elemMatch untuk mempertahankan tipe array dari bidang tersebut.

db.c.drop()
db.c.update(
   { a : { $elemMatch : { $in : [ 2 ] } } },
   { $addToSet : { a: 3 } },
   { upsert: true } )
db.c.find()
{ "_id" : ObjectId("..."), "a" : [ 3 ] }