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.
Have you been working for too long with the new ReferenceField? Because it was an issue before the 0.8 release that you could worked too. Also what version of flask-mongoengine are you using?
Also since the site doesn't have comments include a link to this page in the end?
The thing that changed in 0.8 is that references are now stored as ObjectIds only instead of storing both the table name and the ObjectId (you can still get the old behavior by using dbref=True). However, you would still have to check whether or not the reference was an ObjectId to tell if it was valid.
MongoEngine prefers ODM but documents often have relationships.
That comes at some cost in MongoDB and document databases in general. Often it is best to start with the opposite of modelling a relational db - start denormalised and normalise where it makes sense to.
The catch with MongoEngine is know that ReferenceFields are dereferenced in the application layer and design your Documents accordingly.
No, clearly, its not, since its not object-relational mapping.
And one of the selling points of NoSQL "document store"-style solutions is that, as they do not use the relational model, your data layout can more closely follow object construction and not need the kind of object-(datastore)-mapping represented by ORM, anyway.
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