The micromongo backend is primarily concerned with making sure that we the documents coming out of the database have the same class as the Model classes we’ve defined for those particular collections.
The backend contains a set of minimal subclasses around pymongo to get the desired “as_class” behavior we want without resorting to inspect hackery (which was too slow) or inserting hooks at every unpacking step, subclassing much of pymongo and in the process creating a heavy maintenance burden.
Because the bson wrapping can happen in C code, we don’t have a lot of access to that, so we introduce the concept of a class router which is any function that takes a collection’s full name and returns a new object of the appropriate class to be used as a cursor’s “as_class”.
The class router works via an accounting metaclass that every Model shares. This class maintains a map of collections to model classes to do the proper routing.
Metaclass for all model classes.
This class keeps track of the database & collection that each model covers, and is used by the DocumentClassProxy to look up the right model class to wrap around objects.
The following subclasses are made by the backend:
The Connection object is where the class router is set. If you would prefer, you can create one directly and set your own class router via the class_router keyword argument. This is the actual type returned by micromongo.connect().
The Database object is unmodified from the pymongo class.
The Collection object is unmodified from the pymongo class.
The Cursor class is what is returned when you perform a find, and cloned (or modified) cursors are also returned on subsequent operations like sorts, limits, slices, etc. Micromongo’s Cursor does behave slightly differently from the default in a few key ways.
The first is that these cursors behave more like lazy ORM/ODM querysets than database cursors. Once iterated over, these cursors cache the returned results and can be iterated over again. If you are counting on the default cursor behavior, you should use micromongo.clean_connection() to get a connection that will not exhibit this behavior. This might be required if, for example, your application is using tailable cursors.
A next that caches the returned results. Together with the slightly different __iter__, these cursors can be iterated over more than once.
The cursors are also where the as_class setting for our class router is applied. If you want to avoid this behavior, a clean connection will be required.
Finally, the cursor defines a function, order_by, which is a convenient way to do simple one or two field sorts, inspired by the Django ORM:
An alternate to sort which allows you to specify a list of fields and use a leading - (minus) to specify DESCENDING.
For many simple apps that require only object persistence and simple sorting, it’s generally possible to avoid importing pymongo in code using micromongo, as the only thing you generally need it for if you have a collection object is pymongo.{ASCENDING,DESCENDING}.
To run the tests, you’ll have to clone the repository to get the test suite, and then either use ./setup.py test or a third party test runner such as nose.
In addition to that, you can set the testing environment mongodb settings with the following keys:
If the URI is present, it is used rather than the HOST or PORT parameters.