What Is New in MongoDB 1.2
MongoDB 1.2 delivers a significant performance boost and introduces foundational features that make it more practical for production use. The focus is on faster indexing, better concurrency, and new query operators.
| Category | Key Changes |
|---|---|
| New Features | Index Build in Background, $or operator, unique index constraint |
| Performance | Faster index creation, improved concurrency |
| Database Commands | New dropIndexes command |
| Bug Fixes | Various stability and correctness fixes |
How did indexing get faster in 1.2?
The headline feature is background index building. Before 1.2, creating an index would lock the entire database, making it unusable during the process. This was a major operational headache for any non-trivial dataset.
Now, index creation happens in the background. The database stays responsive for reads and writes while the index is being built. In practice, this means you can add indexes to production collections without scheduling a maintenance window or worrying about downtime.
What new query capabilities were added?
Version 1.2 introduces the $or operator, a fundamental tool for building more complex queries. This
allows you to execute a query where at least one of a set of conditions must be true.
For example, you can now find documents where the status is "A" OR the priority is greater than 5:
db.collection.find({$or: [{status: "A"}, {priority: {$gt: 5}}]}). This opens up many more use cases
that were previously cumbersome or impossible to handle with a single query.
How are data integrity constraints handled?
This release adds support for unique indexes. You can now enforce uniqueness on a field's value
across all documents in a collection, a classic relational database feature that's crucial for preventing
duplicate data.
Creating one is straightforward: db.collection.ensureIndex({username: 1}, {unique: true}). The
database will then reject any insert or update that would create a duplicate username. This matters because it
moves data integrity checks from the application layer into the database itself.
What administrative commands were introduced?
A new dropIndexes command gives admins a way to manage their indexes directly. You can use it to
drop a specific index or all indexes on a collection (except the default _id index).
The syntax is simple: db.runCommand({dropIndexes: "collectionName", index: "indexName"}). This
provides the necessary counterpart to index creation, allowing for full lifecycle management of indexes from the
shell.
FAQ
Does background indexing affect performance while it's running?
Yes, there is still a
performance impact as the database is doing extra work. However, the key difference is that the database remains
operational for both reads and writes, unlike the complete lock in previous versions.
Can I use the $or operator with other query operators?
Absolutely. The $or
operator is designed to be composable. You can combine it with other operators like $gt or
$in within its clauses, and you can also use it alongside other top-level query conditions.
What happens if I try to create a unique index on a collection that already has
duplicates?
The index build will fail. MongoDB will not create the unique index if existing
documents in the collection violate the unique constraint. You must clean up the duplicate data first before
successfully creating the index.
Is it safe to drop indexes in production now?
Dropping an index is a fast, metadata-only
operation. It was already safe and non-blocking in previous versions. The new dropIndexes command
simply provides a standardized way to perform this action.
Should I upgrade to 1.2 for a production system?
If you need to add indexes without downtime
or require the $or and unique constraint features, then yes. Always test the upgrade with a staging
environment that mirrors your production data and workload first.