Introduction
Last updated
Was this helpful?
Last updated
Was this helpful?
Marrow Mongo is a collection of small, focused utilities written to enhance use of the without the overhead, glacial update cycle, complexity, and head-space requirements of stateful active mapper patterns. This project grew out of the need (both personal and commercial) to find a viable, simple, well-tested alternative to existing ODMs. We believe that Marrow Mongo hits the Goldilocks zone for a supportive MongoDB experience in Python without getting in the way, offering elegant and Pythonic approaches to document storage modelling, access, and interaction.
This is a living document, evolving as the framework evolves. You can always within the to review previous versions of these instructions. (Try using the "edit this page" link in the upper right if viewing this document on the .)
Explicit is better than implicit, with fields, traits, and document classes registered as entry_point plugins and made accessible through the standard import mechanism.
Instantiate field objects and associate them with custom Document sub-classes to model your data declaratively.
Utilize Document instances as attribute access mutable mappings with value typecasting, directly usable with PyMongo APIs. Attention is paid to matching Python language expectations, such as allowing instantiation using positional arguments. Values are always stored in the PyMongo-preferred MongoDB native format, and cast on attribute access as needed.
Keep information about your data model with your data model and standardize access.
Construct filter documents through comparison of (or method calls on) field instances accessed as class attributes.
Many Python active record object relational mappers (ORMs) and object document mappers (ODMs) provide a short-hand involving the transformation of named parameters into database concepts.
Every developer has run into those objects that fail to produce sensible or useful programmers' representation, generate meaningless exception messages, or fail to provide introspective help. With more documentation in the code than code, you won't find that problem here. Code should be self-descriptive and obvious; we feel comments and docstrings are integral to this.
You are effectively free to deal in this software however you choose, without commercial hinderance.
marrow.mongo as of a889491
Value
Total Lines
2,976
SLoC
1,479
Logical Lines
840
Tests
305
Functions
57
Classes
41
Modules
23
Average Complexity
2.5
Complexity 95th %
6
Maximum Complexity
17
# > 15 Complexity
1
Bytecode Size
71 KiB
Marrow Mongo comes with batteries included, having extensive support for querying, constructing, and manipulating GeoJSON data.
We utilize continuous integration, with test coverage reporting provided by . We also monitor requirements for security concerns and deprecation using . Extensive static analysis through , proactive use of tools such as with such as the infosec analyzer , and various linting tools help to keep code maintainable and secure.
Changes to the library demand to ensure feature creep and organic growth are kept in check. Where possible, solutions involving objects passed to standard PyMongo functions and methods are preferred to solutions involving wrapping, proxying, or middleware. All but minor changes are isolated in to aid in code review.
The is highly permissive, allowing commercial and non-commercial use, reproduction, modification, republication, redistribtution, sublicensing, and sale of the software (and associated documentation) or its components. The license notice must be included in the reproduced work, and any warranty or liability on behalf of the or waived.
