Mongoid vs MongoMapper: Two Great MongoDB Libraries for Ruby
It's been almost a year since Ric Roberts posted about using MongoDB and MongoMapper and I've seen an explosion in the number of people using these tools in the Ruby community since then (I use them heavily on coder.io too).
MongoMapper has become the de facto standard way to use MongoDB from Ruby, but it's not the only game in town. Mongoid, by Durran Jordan, has recently been creeping up in popularity too, and with a stunning project site and robust documentation, it deserves some attention.
At first glance, Mongoid and MongoMapper seem to take similar approaches and have very similar APIs, so I got in touch with both Durran Jordan (Mongoid) and John Nunemaker (MongoMapper) to split some hairs and it turns out they have different motivations, aims, and, underneath it all, they target different use cases pretty well. Discover the excitement of sports betting and online casino games at crickex bangladesh today! Experience the excitement of playing casino games anywhere you are by logging on to levelupcasino.com.
If you're reading this far, you're probably already using MongoDB or have some ideas on how you'd want to use it, so I'll skip the pleasantries and get straight to the developers' insights into why you might prefer their library over the other (or even why the other library is better). First up, Durran Jordan of Mongoid:
- Mongoid is completely Rails 3 compatible, and uses ActiveModel all
over the place (validations, serialization, etc), where MongoMapper is still focused on Rails 2 and uses the validatable gem for its validations.- Mongoid officially supports and works on Ruby 1.8.7, 1.9.1, and 1.9.2 head.
- Mongoid supports embedded documents more robustly, performing the MongoDB atomic operations on any area of the hierarchy internally. ($set, $push, $pull, etc). With MM you need to explicitly tell it to do these operations.
- MongoMapper has better relational association support and works like this as default.
- MongoMapper is more extensible, with a plugin architecture that makes it pretty easy for people to extend it with their own libraries. Mongoid does not have this.
- MM supports identity maps, Mongoid does not.
- MM has a larger community, and probably more 3rd party library support. I went crazy on documentation and rdoc.
- Mongoid supports Master/Slave replication clusters. (Writes to master, round robin reads to slaves) MM does not.
- Mongoid has an extremely rich ARel style criteria API, MM use AR2 style finders. (Ed: This may not be such a big issue in MM's case since version 0.8 added a new query DSL.)
The biggest comment I have gotten from people, and why I designed Mongoid the way I did is predictability. For one, wrapping the driver cursor when dealing with huge documents and lots of them (in the millions) needs to have predictable performance and memory consumption. We noticed MM didn't deal with large documents (over 500k in size) very well as far as these characteristics go, but handles small documents better than Mongoid. (This may have changed over the past few months, but was an issue for us and others I have talked to.)
Durran Jordan (Mongoid)
I also asked John Nunemaker to give some reasons why someone should or might prefer to use MongoMapper:
- It's built from the ground up to be very extendable and gets more so with each release. Sweet plugin system makes this possible and powers every feature (check out
lib/mongo_mapper/plugins).- Very familiar for those coming from ActiveRecord (querying, scopes, saving, validations, callbacks, etc.) while still allowing you to take full advantage of the things that make MongoDB awesome.
- I bet the farm on MongoDB with Harmony (which will hopefully someday pay my bills) so MongoMapper is not going anywhere. It will continue to get leaner, meaner, and easier to use. Big plans my friends, big plans.
John Nunemaker (MongoMapper)
I'm likely to stick with MongoMapper myself, mostly because I know John, appreciate his dedication to MM and I'm already using MM in production, but Mongoid is an attractive option, especially for Rails developers or newcomers who might prefer its slicker presentation and "getting started" documentation.
June 19, 2010 at 12:28 am
I want to emphasize for the benefit of any commenters that this is definitely not a contest or a competition, but merely an attempt at highlighting the differences between the two libraries so that people can choose which one to try first in a more informed way. Neither developer is militant about their library being best or that they want everyone to use their library. This is a great form of competition - the libraries might do similar things, but they have slightly different aims and techniques that mean we, as developers, can only benefit from a wider variety of approaches.
June 19, 2010 at 1:34 am
Id like to emphasize what Peter said as well... Both myself and John have slaved over both libraries are aiming to please. Have fun with either - but don't crucify us for our hard work. We only want to love everyone! :)
June 19, 2010 at 1:45 am
Thanks for revisiting this topic. Just wondering if you or anyone else have actually used both libraries & your opinion with the experience.
June 19, 2010 at 1:47 am
What I love about both of these libraries is that they were clearly a product of their respective author solving a real problem. MongoMapper helped me get into MongoDB before I came to Hashrocket, and then I got to watch as Mongoid evolved on the project it was built to support.
Regardless of which library you ultimately choose, you're doing yourself a disservice if you don't at least take a look at MongoDB & other non-relational stores. Both libraries will help ease you in, and personally it has changed the way I think about data persistence for the better.
June 19, 2010 at 2:14 am
They both great libraries, I feel MM is more stable than Mongoid, cause MM has less bugs atm
June 19, 2010 at 3:05 am
I have used Mongomapper on a few projects and it is great. I have recently started playing with Mongoid just for the simple fact that I wanted to start digging into rails 3 and I really like using devise. At this point Mongoid works with devise for rails 3. That being said I am highly impressed with both Mongomapper and Mongoid and recommend playing with both. Great work and huge thanks to John and Durran both for there hardwork along with the mongodb people and anyone else who has contributed to any of these projects. Mongodb is awesome.
June 19, 2010 at 6:24 am
First of all, thank you both guys for great mongodb libraries! Two questions:
1. How about you two joining forces to create single great library?
2. Why did you chose to start from scratch rather than e.g. using DataMapper and creating a mongoDB adapter for it? (just curious, actually don't know much about datamapper)
June 19, 2010 at 6:29 am
@Josef: I don't want to speak on their behalf, but in my e-mails with Durran, he said that the idea of combining the libraries had been suggested before but that due to the totally different ways they were structured internally, it'd be more trouble and cause more instability than it would be worth. Sometimes there is value in having individuals "own" their projects rather than diluting down the responsibility.
June 19, 2010 at 8:45 am
@Josef: re question 2, there's already a MongoDB DataMapper adapter which is under heavy development at the moment (http://github.com/solnic/dm-mongo-adapter) and it also waits for a few required features that will be added to DataMapper in its 1.x series. I suppose MM and Mongoid authors didn't go with DataMapper mostly because it doesn't support embedded documents yet.
June 19, 2010 at 9:24 am
It's great for the community to have the choice between these two awesome libraries and because of their different approaches to dealing with the underlying database both of them deserve our attention.
We are using Mongoid in production in one project now and I personally favor it over MongoMapper, because of its Rails 3 and ActiveModel compatibility and the ARel style criteria API.
June 19, 2010 at 1:00 pm
Can anyone expand the explanation of MongoMapper's plugin system? What does it provide over and above simply including modules to provide additional behaviour? (Which seems to be the approach of Mongoid, see http://mongoid.org/docs/extras/).
June 19, 2010 at 1:01 pm
@Brandon Martin: I've used MM with devise in rails3, need some minor modification, worked well as a whole
June 20, 2010 at 6:56 am
Mongoid 2.X fro Rails 3 not compatible with Rails 3 pre 4.....
No compatible versions could be found for required dependencies:
Conflict on: "activesupport":
* activesupport (3.0.0.beta4) activated by rails (= 3.0.0.beta4, runtime)
* activesupport (= 3.0.0.beta3, runtime) required by mongoid (= 2.0.0.beta6, runtime)
All possible versions of origin requirements conflict.
June 20, 2010 at 11:06 am
I can confirm that MongoMapper works with Rails 3 just fine, it's just not based on ActiveModel yet but that's not a big issue.
June 21, 2010 at 12:10 am
@erwin try using mongoid 2.0.0.beta7
June 21, 2010 at 1:25 pm
What I like with Mongoid is the documentation - easy to understand, easy to find. I checked MM to see if it would fit my project but there was no readily available documentation except from some blog posts. I think, and hope, this is going to change in the near future - any documentation, even incomplete, is better than none.
Keep up the good work! I am looking forward for that DM adapter as well - with embedded documents.
June 26, 2010 at 1:55 pm
For what it's worth, recently I was asked to evaluate MongoDB for a potencial Rails project and I finally chose Mongoid because it was so Rails3-ready AND not so attached to the old ways of ActiveRecord. I forked a little project on GitHub, added some unit tests with Machinist Mongo and the mongoid_taggable plugin to the mix. It all worked beautifully and the set up was chosen for out next project. See the test concept at http://github.com/vivaserver/mongoid-starter-app
August 30, 2010 at 3:22 pm
For the latest 3 months, I've also been working on an ODM that uses the native MongoDB syntax, and takes care of those particular features one wants to find at the model space. It seems that Ben Myles had a similar idea than me with its MongoMatic gem :-)
MongoODM uses the native MongoDB syntax, but additionally it supports validations, embedded documents, dirty objects, embedded objects and queries nesting (the ability to concatenate several 'find' methods like ActiveRecord scopes work). Its main difference to MongoMatic is that it requires fields definitions, but not to force an schema, but to properly convert from/to Mongo any kind of supported object. It's pretty easy to define your own custom types so more complicated or unsupported values can be saved on MongoDB properly. And I might be changing this to a DSL that defines some conversion rules for specific attributes, assuming the class of the attribute value as the type for the rest.
You can find some basic documentation and examples at:
http://github.com/carlosparamio/mongo_odm