Version 3.2 of the NoSQL database MongoDB introduces two new interesting features (amongst others) that I’d like to explore in this blog post.
Joins
The logical namespaces where documents are stored are called collections in MongoDB. Up to now every type of query, aggreagtion and even map/reduce job operated on exactly one of these collections.
In version 3.2 the aggregation framework introduces a kind of fetch join that enables you to load documents from more than one collection. Let’s assume the following schema …
| customers | orders |
|---|---|
{ _id: ObjectId(...), vorname: "...", nachname: "...", ... } | { _id: ObjectId(...), customer_id: ObjectId(...), // Foreign Key to customers total: ..., items: [ ... ], ... } |
… and the need to query the customers togehter with their orders. We use this test data set:
1db.customers.insert( {_id: "c1", forename: "Tobias", name: "Trelle"} ); 2db.orders.insert( {_id:"o1", customer_id:"c1", total: 11.50, items:[{desc: "Item 1"}, {desc: "Item 2"}]} ); 3db.orders.insert( {_id:"o2", customer_id:"c1", total: 42.95, items:[{desc: "Item 2"}, {desc: "Item 3"}]} );
Our fetch join from the customers collection to the orders collection uses the new pipeline operation $lookup of the aggregation framework:
1db.customers.aggregate( [ 2 {$match: {_id:"c1"}}, 3 {$lookup: { 4 from: "orders", 5 localField: "_id", 6 foreignField: "customer_id", 7 as: "orders"} 8 } 9] )
The resulting customer document holds the array of orders in the joined field orders:
1{ 2"_id" : "c1", 3"forename" : "Tobias", 4"name" : "Trelle", 5"orders" : [ 6 { 7 "_id" : "o1", 8 "customer_id" : "c1", 9 "total": 11.5, 10 "items" : [ { "desc" : "Item 1" }, { "desc" : "Item 2" } ] 11 }, 12 { 13 "_id" : "o2", 14 "customer_id" : "c1", 15 "total" : 42.95, 16 "items" : [ { "desc" : "Item 2" }, { "desc" : "Item 3" } ] 17 } 18] 19}
Right now, the join condition is expressed on one field on each side, that may become more general in future versions (with multi field join conditions).
Schema Validation
One very fundamental characteristic of document orientation in MongoDB was the schemalessness, i.e. the absence of a validation mechanism that enforces a schema on documents of a collection. You had neither mandatory nor type checking on the fields of a document.
Now you can define a so called validator on the collection level that can perform type checking and even semantic checks:
1db.createCollection("customers", { 2 validator: { 3 name: {$type: "string"}, 4 age: {$type: "int", $gte: 18 } 5 } 6})
We define expected types for the fields name and age. That also makes them mandatory fields. For the field age we define a condition that requires the age to be >= 18. The syntax is more or less the same as with find queries. An invalid document is rejected with an error message:
1db.customers.insert({_id:"c2", name: "Trelle", age: NumberInt(8)}) 2WriteResult({ 3 "nInserted" : 0, 4 "writeError" : { 5 "code" : 121, 6 "errmsg" : "Document failed validation" 7 } 8})
You have to provide an age >= 18 to successfully become a customer:
1db.customers.insert({_id:"c1", name: "Trelle", age: NumberInt(25)}) 2WriteResult({ "nInserted" : 1 })
Conclusion
The fetch joins give you a lot more freedom when designing your schema. You are no longer forced to plan purely query orientated. It also reduces denormalization. Of course, joins will eat up some of your speed. They will impact performance, also in MongoDB.
Schema validation will help you to ensure the semantic consistency of your data. MongoDB can now act as an additional validating instance for your business data. Validation too, will have performance impacts.
With these two new features MongoDB continues providing more and more enterprise readiness. They want to be as powerful as their relational counterparts that offered joins and validation since the beginning of the IT age. MongoDB is becoming an all-purpose database. Let’s see how long this goes along with the basic idea behind the NoSQL movement …
All details and more new features can be found in the release notes of version 3.2 .
Was this post helpful?
More articles
fromTobias Trelle
17.12.2018 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Tobias Trelle
Software Architect
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.