Introducing Version 4.0 of the Mongoose NodeJS ODM

Author: ~ Published: March 30, 2015, 10 a.m.
The MongoDB NodeJS team is excited to announce the latest version, 4.0.0, of the popular Mongoose ODM. In addition to supporting MongoDB server 3.0, Mongoose 4 is packed with exciting new features and improvements. I've already covered some of the highlights, including an improved custom validator API and schema validation in the browser. In this article, you'll learn about two more important features: schema validation for update() and query middleware. Validators for update() and findOneAndUp ...

Announcing Ruby Driver 2.0, a Rewrite

Author: ~ Published: March 27, 2015, 10 a.m.
How rubyists are using MongoDB today Given that the majority of the Ruby community is using Ruby on Rails, the interface for most Ruby users to MongoDB is the mongoid gem, an Object-Document-Mapper that allows Rails to work with the database. This gem is independent of the mongo and bson gems. The mongo gem is the official driver to MongoDB and the bson gem is the serializer/deserializer between BSON documents and Ruby hashes. As I wrote last year, rubyists are at a great advantage in using ...

Introducing the Node.js MongoDB 2.0 Driver

Author: ~ Published: March 25, 2015, 10 a.m.
The marking of of the Node.js MongoDB 2.0 driver as stable is a major leap forward. We’ve made improvements to the codebase that will serve as the foundation going forward. The end result is a better path forward for developers of tools and frameworks who want simple integration with MongoDB. The fundamentals of the driver are now located in the mongodb-core npm package and are meant for people building things like Mongoose, Mongojs and other libraries or frameworks that do not require all the a ...

Announcing the Next Generation Drivers for MongoDB

Author: ~ Published: March 25, 2015, 10 a.m.

When developers get started with MongoDB, they are delighted to discover that it supports the programming languages they love. For as long as the database has been around, we’ve offered at least eight official drivers that help to make developers productive quickly. Moving in lockstep with the server to support all major changes, these drivers ensure that you’re always able to take advantage of the latest features in the database.

Over the years, each driver engineering team has designed its own approach to querying the database, providing fault tolerance, exposing database options, offering an asynchronous interface, and implementing dozens of other features. Each driver has also accumulated its fair share of technical debt, having been initially designed for a much simpler version of MongoDB.

Meanwhile, as MongoDB has proliferated and matured, the number of organizations that use more than one driver has increased. Although each driver strives to be idiomatic in the language it supports, there is little reason why the core CRUD API needs to vary across drivers, and after several years, there was some divergence.

We needed a fresh start, driven by more formal specifications and informed by all the learning we have collectively done since MongoDB was first introduced in 2009. We are excited to announce that in the next few weeks we will be rolling out new drivers for all languages that build on everything we've learned. Stay tuned for major releases from the Java, .NET, Python, Node.js, and Ruby teams. PHP and Perl will follow soon after. An updated C++ driver is also in development.

These new MongoDB drivers conform to published specifications.

  • Server Selection - Deciding which server to send database operations to in a MongoDB deployment.
  • Server Discovery and Monitoring - All the logic required to make a MongoDB application highly available.
  • CRUD API - The API for how we Create, Read, Update and Delete data from MongoDB.
  • Authentication - The rules for how to authenticate to MongoDB servers.

Let us know what you think!

As you are the developers using these drivers every day to access MongoDB, we both value and rely heavily on your input. You directly inform many of the choices made in the specifications. Please continue to give us feedback so we can make the best possible interface for you.

If you’d like to report an issue in a specific driver, please do so in the individual driver project in JIRA (e.g. JAVA, PYTHON). See a full list of our JIRA projects here.

If you’d like to make a feature request or report an issue common to all drivers, please do so in the DRIVERS project.

We look forward to your feedback on this latest release.

About the Author - Andrew

Andrew Erlichson manages the engineering teams that create the developer experience around MongoDB, including MongoDB drivers, Documentation and Education. Prior to MongoDB, Andrew was CEO and founder of Phanfare, an online photo hosting company, now part of Carbonite. Prior to Carbonite, he was founder and CEO of Flashbase, a web service that offered self-service online database forms and analysis tools. Flashbase was acquired by DoubleClick. At DoubleClick, Andrew was Vice President of Technology for the Research and Development group. He has worked at Mips Computer Systems, Silicon Graphics and BlackRock. Andrew received his A.B. from Dartmouth College and his M.S. and Ph.D. in Electrical Engineering from Stanford University.

Creating a Single View Part 3: Data Design and Loading Strategies

Author: ~ Published: March 23, 2015, 10 a.m.
In part 1 of this series on single views, we wrote about why to build a single view with MongoDB, while in part 2, we looked at the implementation of an example single view data model. This week, we’re talking about how to actually get your data into your now single view. It’s 2015. Moving data from one place to another should be simple, right? Of course, anyone who’s ever tried it knows that it’s not. Why Is This Still Hard? It seems simple. You have data in one system, and it works gr ...

Wired Tiger - how to reduce your mongdb hosting costs 10x

Author: John Page ~ Published: March 19, 2015, 1:02 p.m.
Forgive me father, it’s been a long time since I last blogged - I've been giving in to temptation and getting to grips with MongoDB 3.0 and Wired Tiger Storage (WT) - and I've learned some things I'd like to share.Much has been said about WT's ingestion speed and the fine grained concurrency that allows it to rocket through mixed workloads. Playing with the POCLoader ( ) I've seen some incredible throughput - occasionally into 7 figures per second of transac ...

Operations Best Practices Part 2: Managing MongoDB

Author: ~ Published: March 19, 2015, 10 a.m.
Welcome to our multi-part series on operations best practices. This post -- the second of three -- focuses on how to best run MongoDB in your datacenter. Download the MongoDB Operations Best Practices guide for more detail. Manage MongoDB with Ops Manager We recommend you install Ops Manager in your data center if you manage large scale MongoDB deployments. Ops Manager can alleviate the overhead of operating MongoDB deployments by as much as 95%. If you prefer a cloud-hosted service, you can u ...

How to upgrade your MongoDB deployment to 3.0 version

Author: Cesar Trigo ~ Published: March 18, 2015, 7:49 p.m.
It is the moment to upgrade our MongoDB installation, do we know how to do it? In this post we will explain how to achieve it for all sort of deployments, a stand-alone node,...

PyMongo And Key Order In Subdocuments

Author: A. Jesse Jiryu Davis ~ Published: March 18, 2015, 6:18 p.m.

Or, "Why does my query work in the shell but not PyMongo?"

Variations on this question account for a large portion of the Stack Overflow questions I see about PyMongo, so let me explain once for all.

MongoDB stores documents in a binary format called BSON. Key-value pairs in a BSON document can have any order (except that _id is always first). The mongo shell preserves key order when reading and writing data. Observe that "b" comes before "a" when we create the document and when it is displayed:

> // mongo shell.
> db.collection.insert( {
...     "_id" : 1,
...     "subdocument" : { "b" : 1, "a" : 1 }
... } )
WriteResult({ "nInserted" : 1 })
> db.collection.find()
{ "_id" : 1, "subdocument" : { "b" : 1, "a" : 1 } }

PyMongo represents BSON documents as Python dicts by default, and the order of keys in dicts is not defined. That is, a dict declared with the "a" key first is the same, to Python, as one with "b" first:

>>> print {'a': 1.0, 'b': 1.0}
{'a': 1.0, 'b': 1.0}
>>> print {'b': 1.0, 'a': 1.0}
{'a': 1.0, 'b': 1.0}

Therefore, Python dicts are not guaranteed to show keys in the order they are stored in BSON. Here, "a" is shown before "b":

>>> print collection.find_one()
{u'_id': 1.0, u'subdocument': {u'a': 1.0, u'b': 1.0}}

To preserve order when reading BSON, use the SON class, which is a dict that remembers its key order. First, get a handle to the collection, configured to use SON instead of dict. In PyMongo 3.0 do this like:

>>> from bson import CodecOptions, SON
>>> opts = CodecOptions(as_class=SON)
>>> opts
CodecOptions(as_class=<class 'bson.son.SON'>,
>>> collection_son = collection.with_options(codec_options=opts)

Now, documents and subdocuments in query results are represented with SON objects:

>>> print collection_son.find_one()
SON([(u'_id', 1.0), (u'subdocument', SON([(u'b', 1.0), (u'a', 1.0)]))])

The subdocument's actual storage layout is now visible: "b" is before "a".

Because a dict's key order is not defined, you cannot predict how it will be serialized to BSON. But MongoDB considers subdocuments equal only if their keys have the same order. So if you use a dict to query on a subdocument it may not match:

>>> collection.find_one({'subdocument': {'a': 1.0, 'b': 1.0}}) is None

Swapping the key order in your query makes no difference:

>>> collection.find_one({'subdocument': {'b': 1.0, 'a': 1.0}}) is None

... because, as we saw above, Python considers the two dicts the same.

There are two solutions. First, you can match the subdocument field-by-field:

>>> collection.find_one({'subdocument.a': 1.0,
...                      'subdocument.b': 1.0})
{u'_id': 1.0, u'subdocument': {u'a': 1.0, u'b': 1.0}}

The query matches any subdocument with an "a" of 1.0 and a "b" of 1.0, regardless of the order you specify them in Python or the order they are stored in BSON. Additionally, this query now matches subdocuments with additional keys besides "a" and "b", whereas the previous query required an exact match.

The second solution is to use a SON to specify the key order:

>>> query = {'subdocument': SON([('b', 1.0), ('a', 1.0)])}
>>> collection.find_one(query)
{u'_id': 1.0, u'subdocument': {u'a': 1.0, u'b': 1.0}}

The key order you use when you create a SON is preserved when it is serialized to BSON and used as a query. Thus you can create a subdocument that exactly matches the subdocument in the collection.

For more info, see the MongoDB Manual entry on subdocument matching.

Leaf in the Wild: Brein BV Powers Next-Generation SaaS Platform with MongoDB

Author: ~ Published: March 18, 2015, 10 a.m.
23x Higher Performance, Delivered to Market in Just 6 Months, Weekly Product Updates Brein BV powers mission critical government services in the Netherlands. Migrating from its previous content management platform in just 6 months, Brein BV is now delivering 23x higher performance for its customers, and updating its service weekly. I had the chance to sit down with Ronald Brinkerink, CEO and founder of Brein BV to learn more about how and why his team uses MongoDB, and his recommendations for ...