Is umongo possible and safe to be used with something like aiocache ?

[hydridity]

I have a situation where functions upon calling needs to follow logic based on values retrieved from document stored in database (basically preferences document), while this won't be problem in small amounts, this function's usage can scale up very fast and I think it might cause unnecessary bottleneck while waiting for driver to load data from database, so I was thinking it would be best if I cache them in either REDIS based cache, or simple memory cache until this document is changed from different function and updated in database (which would invalidate cache ...)

While umongo has tight integration with Marshmallow, aiocache can use Marshmallow as serializer, would it be possible to integrate umongo and aiocache together maybe by obstrufucating umongo instance loading functions to either to load from cache or database or it would need different approach ?

I'm using motor as async driver that's why aiocache.
https://github.com/aio-libs/aiocache

[lafrech]

You could try to override methods in umongo.frameworks.motor_asyncio.py.

I can't tell right away if it is better to do it at framework level as you're suggesting or more explicitly in app logic.

But I agree it is tempting to do it at framework-level so that it is transparent to the app.

[hydridity]

After some research, rather than obstructing how umongo works with motor, I think it would be better to put one more interface between application and how umongo provides client world view so it would preserves the umongo's ability of multi-driver support by using aiocache for async drivers, and something else for non async drivers, so the caching interface would consume data from umongo's client world either by the Marshmallow schemas, or as an dumped document in json format.

But i'm stuck on how to properly dump and then load the existing document back and forth from and to umongo's Object Oriented world

In case of Marshmallow approach I'm having trouble finding if it's possible to populate converted umongo schema via *.as_marshmallow_schema with existing data from that document for caching, and then loading that cached data back to umongo object oriented world for reading or for editing and then committing to database

In case of json dumping and loading, I would like to ask how to properly handle the document id (_id) while dumping the document from Object Oriented world and back since DocumentImplementation.dump() gives the Mongodb's _id field as id which umongo won't accept while loading it back to defined model, so do I have to edit the id key to Mongodb's ObjectId("") format, or should I use the to_mongo() which gives the id in proper Mongodb's ObjectId("") format which should I in turn edit to {'_id': '"'} format ?

What i'm trying to achieve is something like:

1. New preference instance is created, that would commit umongo's model with default values to database, and the document gets cached
2. When the preference instance is being read or edited it would retrieve it from cache, construct it back to umongo's Object Oriented world, so the application can work with the data in umongo's object oriented world
3. If the given document is edited, it would be committed to database and the updated version would be cached