(+N) Consulting Inc.

Consulting | Software Solutions | Training

MongoDB 3.2 Goodies Coming Your Way: More ways to $unwind

The aggregation framework has a slew of new operators and pipeline improvements. One notable improvement is the more robust $unwind pipeline stage. One of the main motivations for using Mongo is its flexible document model. Any document in a collection can have arbitrarily different fields and data types in fields. This is great for many reasons. But when it came to aggregating array elements it posed a few problems. Unwinding an array is done with the $unwind pipeline stage, but you could only specify the field to unwind. Problem one was that the variety across documents created for non-existent arrays. Consider a cake collection, containing documents about cakes. > db.cakes.find(){ "_id" : "pound cake", "recipe" : [ "butter", "flour",... [More]

MongoDB 3.2 Goodies coming your way: Schema Validator

Mongo has a flexible document model, allowing you to pretty much save any data you want, any way you want, without any ceremony around declaring your document structure ahead of time. This makes some folks uneasy. After all, if there's no schema structure enforcement, what prevents humans from making silly programming errors like naming a field "wrong" of storing a number as a string and not an integer? The data integrity or coherency surely can kick you in the rear binary area. On the other hand, documents are really cool. The inherent flexibility lets us ingest arbitrary variety of data and deal with fields and sub-documents as first class citizens with rich query and update operators. This is not something we want to give up. So what to do... [More]

MongoDB 3.2 goodies coming your way: Partial Indexes

MongoDB includes sparse indexing for a while now. What is a sparse index? A sparse index is space optimized index which only contains pointers to documents that contain value(s) in the indexed fields. Lets say our Person collection had a document for each user in our system. All people have to supply a first name. But the prefix is optional. Some people have a "Mrs" or 'Prince' or something, but most users don't: { _id: 1, name: 'Jan', prefix: 'Mrs' }{ _id: 2, name: 'Dude' } Jan (in our contrived example) has a prefix, but Dude doesn't. Now if we created an index on the field "prefix", then an entry for both documents would be created. The key "Mrs" would point to the document with _id 1 (and any other documents with the prefix "Mrs", and th... [More]

Node Mongoose Demo Code to ignore

There's lots of "getting started" tutorials out there. Some are great, but some, well, shall we say "sub-optimal"? When using Mongoose, you get an entity-centric model to work with. Very often, it becomes the basis for a RESTful API. The verb mapping typically just rips through POST, GET (list) and GET (one by _id) and DELETE no problem. When it comes to PUT though, things become a bit trickier. Genereally understuood simply as an "update", implementing PUT can get you into all sorts of funkiness. The code to ignore in general is something to this effect: (error checking removed for brevity) // define schema for Animalvar AnimalSchema = new Schema({ name: String isCute: Boolean});module.exports = mongoose.model('Animal', AnimalSchema)... [More]

Who would save() me now? MongoDB 2.0 C#Driver deprecates save()

For years now, I've been using mongo's save() function on a collection. It's convenient: hand it an document with an id, slam it in and done. With the C# 2.0 driver, (and other drivers as well) it's now gone! Will we miss it? Should we miss it? Lets take a closer look: First – what is the syntactic meaning of "save"? The save function provided add-or-replace semantics . If an document by that id existed, it would be overwritten with the new document . If an document with that id did not exist, then the document at hand would become a new document. Seems legit, right? Consider though, what would happen when a document already existed. It would be gone. Gone in the sense that the new document would overwrite the existing one. I know, I know. W... [More]

Of transactions and Mongo

What's the first thing you hear about NoSQL databases? That they lose your data? That there's no transactions? No joins? No hope for "real" applications? Well, you *should* be wondering whether a certain of database is the right one for your job. But if you do so, you should be wondering that about "traditional" databases as well! In the spirit of exploration let's take a look at a common challenge: You are a bank. You have customers with accounts. Customer A wants to pay B. You want to allow that only if A can cover the amount being transferred. Let's looks at the problem without any context of any database engine in mind. What would you do? How would you ensure that the amount transfer is done "properl... [More]