Docs Menu

Docs HomeDevelop ApplicationsPython DriversPyMongo

Third-Party Tools

On this page

  • Overview
  • ORM-like Layers
  • Framework Tools
  • Django
  • Flask
  • Other Tools
  • Interoperability Tools
  • gevent
  • mod_wsgi
  • Alternative Python Drivers

This page describes some popular third-party libraries for working with PyMongo. With the exception of Motor, all libraries on this page are maintained by the community. To keep this list current, projects that haven't been updated recently will occasionally be removed from the list or moved to the end.

Tip

Although these libraries can be helpful, we recommend that new PyMongo users begin by working directly with the driver. PyMongo alone will meet most people's needs, and working with it is instructive in how MongoDB works.

ORM-like (object-relational-mapping-like) layers add features like models and validation to PyMongo.

  • MincePy is an object-document mapper (ODM) designed to make any Python object storable and queryable in a MongoDB database. It was designed with machine learning and big-data computational and experimental science applications in mind. However, it's entirely general and can be useful to anyone looking to organize, share, or process large amounts of data with as little change to their current workflow as possible.

  • Ming is a library that allows you to enforce schemas on a MongoDB database in your Python application. It was developed by SourceForge in the course of their migration to MongoDB. See the introductory blog post for more details.

  • MongoEngine lets you use syntax inspired by the Django ORM to define schemas for documents and query collections. The code is available on GitHub.

  • MotorEngine is a port of MongoEngine to Motor, allowing asynchronous access with Tornado. It implements the same modeling APIs in a data-portable way, meaning that a model defined in MongoEngine can be read in MotorEngine. The source is available on GitHub.

  • uMongo is a Python MongoDB ODM that was created to meet two needs: the lack of an asynchronous ODM and the difficulty of serializing documents with other ODMs. uMongo works with multiple drivers: PyMongo, TxMongo, motor_asyncio, and mongomock. The source is available on GitHub.

This section lists tools and adapters that have been designed to work with various Python frameworks and libraries.

Even without a Django backend, you can use MongoDB and PyMongo with most of what Django provides. Certain features of Django that require django.db, such as admin, authentication, and sessions, will not work when using only MongoDB.

  • Django MongoDB Engine is a MongoDB database backend for Django that supports Django aggregations, atomic updates, embedded objects, Map/Reduce, and GridFS. It allows you to use most of Django's built-in features, including the ORM, admin, authentication, site and session frameworks, and caching. For more information, see the Django MongoDB Engine tutorial.

  • Django MongoEngine is a MongoDB backend for Django. The repository also includes an example application. For more information, see the Django MongoEngine documentation.

  • Djongo is a connector for using Django with MongoDB as the database backend. With Djongo, you can use the Django Admin GUI to add and modify documents in MongoDB. The Djongo source code is hosted on GitHub, and the Djongo package is on PyPI.

  • mango provides MongoDB backends for Django sessions and authentication (bypassing django.db entirely).

  • Log4Mongo is a flexible Python logging handler that can store logs in MongoDB by using normal and capped collections.

  • mongobox is a tool to run a sandboxed MongoDB instance from within a Python app.

  • mongodb_beaker enables you to use MongoDB as a backend for Beaker's caching and session system. The source is on GitHub.

  • MongoLog is a Python logging handler that stores logs in MongoDB by using a capped collection.

  • rod.recipe.mongodb is a Buildout recipe for downloading and installing MongoDB.

This section lists tools that support interopability with other tools.

PyMongo uses thread and socket functions from the Python standard library. By using gevent, PyMongo can do asynchronous I/O with non-blocking sockets and schedule operations on greenlets instead of threads.

To use gevent with PyMongo, call gevent's monkey.patch_all() method before loading any other modules, as shown in the following example:

# You must call patch_all() *before* importing any other modules
from gevent import monkey
_ = monkey.patch_all()
from pymongo import MongoClient
client = MongoClient()

Important

Close MongoClient to Avoid Blocking

If you call monkey.patch_all() when your application launches, MongoClient will use greenlets instead of threads to monitor the health of the server. When shutting down, if your application calls the ~gevent.hub.Hub.join() method without first terminating these greenlets, the call to the ~gevent.hub.Hub.join() method blocks indefinitely.

To avoid this, close or dereference any active MongoClient objects before exiting your application. In some application frameworks, you can use a signal handler to end background greenlets when your application receives SIGHUP, as shown in the following example:

import signal
def graceful_reload(signum, traceback):
"""Explicitly close some global MongoClient object."""
client.close()
signal.signal(signal.SIGHUP, graceful_reload)

This issue affects applications using uWSGI versions earlier than 1.9.16 or newer uWSGI versions with the -gevent-wait-for-hub option. For more information, see the uWSGI changelog.

The mod_wsgi package provides an Apache module that implements a WSGI-compliant interface for hosting Python-based web applications on top of the Apache web server.

To run your PyMongo application under mod_wsgi, follow these guidelines:

  • Use the WSGIDaemonProcess directive to run mod_wsgi in daemon mode. If your mod_wsgi configuration includes only the WSGIScriptAlias directive, it will run in embedded mode.

  • Use the WSGIApplicationGroup %{GLOBAL} directive to ensure your application runs in the daemon's main Python interpreter, rather than a sub-interpreter. This avoids a small cost incurred when decoding BSON in a sub-interpreter.

  • Use the WSGIProcessGroup directive to assign each application to a separate daemon. This ensures the applications don't affect each other's state.

The following mod_wsgi configuration shows how to use the preceding directives to run your PyMongo application:

<VirtualHost *>
WSGIDaemonProcess my_process
WSGIScriptAlias /my_app /path/to/app.wsgi
WSGIProcessGroup my_process
WSGIApplicationGroup %{GLOBAL}
</VirtualHost>

If you have multiple PyMongo applications, put each in a separate daemon in the global application group:

<VirtualHost *>
WSGIDaemonProcess my_process
WSGIScriptAlias /my_app /path/to/app.wsgi
<Location /my_app>
WSGIProcessGroup my_process
</Location>
WSGIDaemonProcess my_other_process
WSGIScriptAlias /my_other_app /path/to/other_app.wsgi
<Location /my_other_app>
WSGIProcessGroup my_other_process
</Location>
WSGIApplicationGroup %{GLOBAL}
</VirtualHost>

Note

Many Python C extensions have issues when running in multiple Python sub-interpreters. These difficulties are explained in the documentation for Py_NewInterpreter and in the Multiple Python Sub Interpreters section of the mod_wsgi documentation.

This section lists alternatives to PyMongo.

  • Motor is a full-featured, non-blocking MongoDB driver for Python Tornado applications.

  • TxMongo is an asynchronous Twisted Python driver for MongoDB.

  • MongoMock is a small library to help test Python code. It uses PyMongo to interact with MongoDB.

← Universally Unique IDs (UUIDs)