On 01/05/2016 06:56 PM, cyril.boutei...@clearlabs.com wrote: > I'm working on a new project written in Python with Flask & SQLAlchemy. > The latter seems like a fine ORM but doesn't seem to consider caching as > its responsibility. > > It provides some examples on how to leverage dogpile.cache @ > http://docs.sqlalchemy.org/en/latest/orm/examples.html#module-examples.dogpile_caching > but this seems to offer no more than basic query results caching which > is really only valuable for read-only models.
it's listed as an example so that one can see how it works fully. You can alter it to handle invalidate-on-write as well. > > What I am looking for is a real Level 2 Object Cache integrated into the > ORM which store each object via its PK and ensures identity in a > concurrently shared cache. the identity map does this on a per-Session basis but it isn't concurrent across multiple threads or processes. That would defeat its purpose as it would work against transaction isolation, allowing concurrent modifications to a shared object. You can hook into the lifecycle of the identity map using events and share state out to a cache of some kind but I'm not deeply familiar with what the use case would be for that unless your application is very heavy on get-by-primary key. A dogpile.cache recipe that does simple caching of get-by-pk with expire-on-write is pretty easy to work up. > I have experience with multiple caching > libraries working with Java ORMs I've worked a lot with hibernate and that was sort of why I made the choice to not go out and copy *every* feature they had. Certainly if SQLA were as large and funded of a project as Hibernate, such features would be more likely though I'd likely keep 2nd level cache integration as a separate project in any case, e.g. the extremely broad expanse of Hibernate itself would totally not fly in the Python world, SQLA's breadth is already too much for a lot of folks. but I'm not able to find anything for > SQLAlchemy. I saw a few posts from people who tried to do this, but this > is complex stuff. Does no such maintained object caching project exist > for SQLAlchemy? dogpile.cache remains as a "do it yourself" system precisely for this reason. If it were an off-the-shelf thing, the amount of user confusion and requests for behaviors/features/bug fixes would be overwhelming - just that for the ORM and Core alone is an enormous burden. Having the user pay the price of investing in an understanding of the mechanics of caching is how we keep that from happening further. that said there certainly may be projects on pypi which attempt to do this, if you search for "sqlalchemy": https://pypi.python.org/pypi?%3Aaction=search&term=sqlalchemy&submit=search there's many hundreds of results: https://pypi.python.org/pypi/Flask-SQLAlchemy-Cache/ seems like it might be relevant, though this is perhaps just the dogpile example packaged. > > -- > You received this message because you are subscribed to the Google > Groups "sqlalchemy" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to sqlalchemy+unsubscr...@googlegroups.com > <mailto:sqlalchemy+unsubscr...@googlegroups.com>. > To post to this group, send email to sqlalchemy@googlegroups.com > <mailto:sqlalchemy@googlegroups.com>. > Visit this group at https://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
