I have been going back and forth over which Python API to use when interacting with Mongo. I did a quick survey of the landscape and identified three leading candidates.
If you were designing a new content-heavy website using the django framework, what API would you choose and why?
MongoEngine looks like it was built specifically with Django in mind. PyMongo appears to be a thin wrapper around Mongo. It has a lot of power, though loses a lot of the abstractions gained through using django as a framework. Ming represents an interesting middle ground between PyMongo and MongoEngine, though I haven’t had the opportunity to take it for a test drive.
Both MongoEngine and Ming depend on PyMongo – they just put some nice functionality on top of it. I’d recommend at least starting w/ PyMongo directly – that way if you decide to use one of the other tools and run into issues it will be easy to understand what is going on “under the hood”. That said, I’m highly biased ;).
I’ve been working with Mongokit. Like it so far.
As Mike says, you can’t avoid PyMongo – all the other interfaces build on top of it. These other interfaces are arguably unnecessary. ORMs such as that used in Django are useful when dealing with SQL because they mitigate the complexity of creating SQL queries and schemas, and parsing result sets into objects.
PyMongo however already has that covered – queries go through a convenient and simple API and results coming from MongoDB already are objects (well, dicts in Python – same difference) by definition. If you feel that you really need to decorate your Mongo documents with Python objects, it’s easy to add a SON manipulator to PyMongo. The nice thing about this approach is that you can write code directly on PyMongo, and slide in additional functionality later on without having to insert a new API between your code and PyMongo.
What’s left? Schema creation and migration are somewhat useful, but are almost as simply done ad-hoc – chances are if you’re considering using MongoDB you want to break out of the traditional SQL-style model anyway. Also, if there were a fully Django-compatible MongoDB ORM you might get some mileage out of it. Anything less than that and you will probably be creating work for yourself.
You won’t regret using PyMongo directly.
One last option worth watching if you are interested in top efficiency is the asynchronous version of PyMongo, here: http://github.com/fiorix/mongo-async-python-driver
You might give django-mongodb-engine a try. It’s a backend for Django-nonrel, so you can continue to use Django’s models and ORM. It’s not yet as complete as the other APIs, though:
I just found ‘micromongo’:
Looks like it adds just enough useful stuff on top of pymongo without getting in the way.
You don’t need django-nonrel to run it.
All native Django contrib modules (eg. admin, user, session) work without any modification.
MongoEngine requires rewriting contrib modules and last I checked, the native admin module didn’t run on MongoEngine.
Your existing models run without any ORM translation as well.