Hi Mike, I'll let the others add more detail about your questions, but for the broad strokes I thought I'd add that I ran into similar issues with my simple caching method and ultimately ended up using the new Dogpile.cache stuff that Mike recommended on his blog<http://techspot.zzzeek.org/2012/04/19/using-beaker-for-caching-why-you-ll-want-to-switch-to-dogpile.cache/>. (The example file is here: https://groups.google.com/d/msg/sqlalchemy/MrKA6AygZ14/o95dmUdLS70J ) It is far more integrated with the internals of SQLAlchemy relationship management, so it may behave better.
On Thursday, September 27, 2012 7:28:12 AM UTC+2, mikepk wrote: > > Unlike most of the SQLAlchemy caching examples, I'm not using query-level > caching but rather caching at the instance / object level. I'm using the > ORM and I have a SQLAlchemy object that I load and occasionally store in a > second level cache. I have a custom 'get' loading function that checks the > second level cache based on primary key and returns the cached copy if > present and populates the cache if not. > > I also have an event handler on 'after_commit' that checks the session for > dirty objects that are cached (with a simple class property of > __cached__=True) and does either an invalidate or write-back to the cache > when these objects are dirty and cached. > > This pattern is pretty simple and works great. > > My problem is that I'd like to be able to use this same (or similar) > pattern for more complex SQLAlchemy objects containing relationships. I'd > like the cache to contain not only the 'base' object but all (lazy) loaded > related obejcts. I have no problem storing and retrieving these objects > (and relationships) from the cache, my problem comes from the > invalidation/write-back part. > > Lets say I have object A that's in the cache and it has a relationship, > A.B that was stored along with it in the cache. If I retrieve A from the > cache I can get A.B and I get the cached copy of B. If B is modified, > however, then my simple cache invalidator event handler doesn't see that B > is cached (no __cached__ property on B) and B gets committed to the > database without the cached copy of A being invalidated. Now subsequent > cache hits of A will have a stale A.B relationship. > > So my question is, is there a clean / simple way to mark A for > invalidation when B is modified? I've come up with a few schemes but all of > them seem brittle, complicated, and my intuition is telling me that I'm > reinventing the wheel; that some facility in SQLAlchemy itself may be > useful in walking this relationship graph to find loaded, connected > relationships who's cached represenations might need to be invalidated. > Alternatively, is there another pattern that would be better suited to this > kind of object-level caching? > > Thanks! > -Mike > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/s9rf5eY9f2IJ. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
