Latest in branch 1.2
1.2.5
Released 07 Apr 2010
(16 years ago)
SoftwareMongoDB Server
Version1.2
Status
End of life
Initial release1.2.0
10 Dec 2009
(16 years ago)
Latest release1.2.5
07 Apr 2010
(16 years ago)
End of life30 Jun 2011
(Ended 14 years, 11 months ago)
Release noteshttps://www.mongodb.com/docs/manual/release-notes/1.2/
Documentationhttps://www.mongodb.com/docs/v1.2/
Downloadhttps://www.mongodb.com/try/download/community
MongoDB Server 1.2 ReleasesView full list

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.

Releases In Branch 1.2

VersionRelease date
1.2.507 Apr 2010
(16 years ago)
1.2.402 Mar 2010
(16 years ago)
1.2.323 Feb 2010
(16 years ago)
1.2.226 Jan 2010
(16 years ago)
1.2.130 Dec 2009
(16 years ago)
1.2.010 Dec 2009
(16 years ago)