For a project I’m currently working on, I needed to be able to update the status of a document.
For example, let’s assume it’s an Order.

I need to create it, then set it’s status to ‘Pending’
When the Payment is completed, I need to set it to ‘Paid’
Then, as the order progresses, I need to set it to ‘Packed’, finally ‘Dispatched’

I also need to keep a history of status updates, for audit / logging reasons.

So, I created Mongoose Status Manager

This makes it as easy as:

It’s important to note that changes aren’t persisted until .save() is called.

Full documentation is available on the README on the github page

Available on github

I’ve used MongoDB with several net projects over the last few years, and one thing that has in the past frustrated me is the way BsonMapping  is set up.

This once per app setup can get pretty long, complex and hard to follow.

As per the documentation this, on the face of it,  it’s fairly easy:

Which will automap MyClass.
Note – There is no actual need for this line of code.

You can either create this class map yourself or simply allow the class map to be created automatically when first needed (called “automapping”). If you want to customise the mapping of your class, you can provide a lambda to the generic RegisterClassMap method:

… with many options and arguments on MapProperty, which I won’t go into in this post. But what if we have many classes in our domain? Well, with the current set up, we’d have to call RegisterClassMap  once per domain somehow (Global.asax, App start, etc.. are common places)

I prefer to keep things separate, and think that the way fluent nHibernate ClassMap handles this is great.
I wanted something similar for my MongoDB projects, so I use the following pattern and set of classes.

Firstly, we create an abstract class to act as a base class for our class maps. The constructor checks if we already have a class map of that type (passed in by generic) If not, we call our abstract Map void by delegate.

Then create a class, inheriting from MongoDbClassMap, like this:

You would have one of these per class you want to map, keeping things nice and separate. Now, all you need to do, is new up an instance of each of your *ClassMap classes.
There are several ways to do this.
One, is to do it manually.
I don’t recommend this; You WILL forget to add one to the list of new *ClassMap() calls, I promise!

The way I handle this is with reflection. Since we’re only doing this once per app domain (on startup) this fairly expensive operation is excusable.

I have created a github repository for this example –
(for those not familiar with git, you can download a zip here)
I’ve used a separate branch, as I want to formalise this into a reusable nuget package, subject to community approval!

I blogged about using incremental ids with mongodb previously, so have a read of that for more information.

Although it’s not ideal, we can use sequential / incremental IDs with MongoDB.
Sometimes (when migrating legacy systems for example) we just can’t get away from using ints for id’s.

While working on implementing MongoDB with N2CMS recently, I came across this very problem.

All IDs are integers, and this can’t be changed
(technically, it could… but I don’t think it’s appropriate… yet)

So, we needed to find a way of generating incremental IDs

Fortunately, the MongoDB driver for .net allows us to write and use our own IdGenerators

So, with that in mind, I’ve created this:

It works on the principal outlined in my previous blog post:
Have a collection that keeps track of collection names, and increment their sequence each time one is inserted

This works well, on single server setups.

I have not yet tested on other setups, but intend to soon.

While playing with incremental IDs with Mongo DB the other day, I stumbled across a bug in mongodb.

Consider the following command:

Notice the fields:{"_id":0}, part (highlighted)

According to the documentation, this should prevent the id from being returned, however when I try and execute this command, I get this error:

Uncaught exception: findAndModifyFailed failed: "exception: assertion c:\\builds\laves\\mongo\\windows_64bit_v1.6\\mongo\\db\\../bson/bsonbjbuilder.h:115"


I opened a ticket with their issue tracking system (Jira)

After a day or so, I had a response that this was caused by a limitation to how FindAndModify was implemented.

Luckily, they’re planning on re-implementing this feature (see this ticket) which should remove this restriction.

In the meantime, the method of auto-incrementing ID’s described in my previous post will still work, but it will return the _id as well.

In a future release of mongodb, we’ll be able to strip this out, and make it even speedier!

MongoDB – Incremental IDs

I’ve been reading a lot recently on MongoDB and the use of incrementing an ID

This article offers an in depth look:

Taking this a little further, and from reading the findAndModify documentation I put together the following:

Here is what this command does:

  • Finds (or creates) the “sequence” collection
  • Gets the document with id “customer”
  • Increments the value of “seq” by 1
  • If this document doesn’t exist, it creates it (upsert:true)
  • Returns the new value of “seq”

Of course, in production, I’d shorten “seq” to just “s” or something like that, for even speedier responses!

The advantages of this are you don’t need to initialise your “sequence” collection first, or check if your document exists first. If it doesn’t exist, it will create it!

Important Note

At the time of writing, unfortunately, the whole document (ie- id and seq) is returned with this operation

According to the documentation, we should be able to specify “fields” to remove the id from the returned doc, however this doesn’t seem to work.

I have opened a ticket on MognoDB Jira for this.

See this post for more information.