I used Mongo in Python for a couple of projects recently. I tried out every single library I could find. In the end I settled on using Schematics [1] with a very thin data layer for loading and saving the objects. It worked really well. You get to work with sane Python objects and it's really easy to move between Mongo and Python.
Ultimately, two projects later I'm just not happy with Mongo as a data store. I've found that the restrictions of a relational data model mean that you don't end up paralysed worrying about how to store your data. In Mongo I was forever tossing up between embedding data or splitting it up into a separate collection. And it's a choice that may well bite you later. Also, only ensuring the integrity of your data within the application is not a great idea.
Regarding schematics: We actually developed a object validation library that's very similar to it. It's called cleancat. It comes with some MongoEngine-specific fields to validate references. It's best to look at the unit tests to see how it works: https://github.com/elasticsales/cleancat/blob/master/tests/_...
Regarding collections and embeddeded documents: Yes, a lot of times it makes sense to split things out into separate collections instead of embedding them so you don't run into problems later. One nice thing about MongoEngine and MongoMallard is that they update only fields that have changed. So if you have a ListField(EmbeddedDocumentField()) and change one of the embedded documents, only that document gets sent in the update statement, which speeds things up. And yes, I wish MongoDB had better ways to ensure data integrity.
Comments
I used Mongo in Python for a couple of projects recently. I tried out every single library I could find. In the end I settled on using Schematics [1] with a very thin data layer for loading and saving the objects. It worked really well. You get to work with sane Python objects and it's really easy to move between Mongo and Python.
Ultimately, two projects later I'm just not happy with Mongo as a data store. I've found that the restrictions of a relational data model mean that you don't end up paralysed worrying about how to store your data. In Mongo I was forever tossing up between embedding data or splitting it up into a separate collection. And it's a choice that may well bite you later. Also, only ensuring the integrity of your data within the application is not a great idea.
[1] https://github.com/j2labs/schematics
Regarding schematics: We actually developed a object validation library that's very similar to it. It's called cleancat. It comes with some MongoEngine-specific fields to validate references. It's best to look at the unit tests to see how it works: https://github.com/elasticsales/cleancat/blob/master/tests/_...
Regarding collections and embeddeded documents: Yes, a lot of times it makes sense to split things out into separate collections instead of embedding them so you don't run into problems later. One nice thing about MongoEngine and MongoMallard is that they update only fields that have changed. So if you have a ListField(EmbeddedDocumentField()) and change one of the embedded documents, only that document gets sent in the update statement, which speeds things up. And yes, I wish MongoDB had better ways to ensure data integrity.
Schematics was an early fork of MongoEngine - focusing on data modelling and validation of various data formats, dicts, json & bson documents.
Interesting. I know it's a rework of DictShield but I was unaware that came from MongoEngine.