On Jul 9, 2011, at 3:51 PM, Michael Bayer wrote: > > On Jul 9, 2011, at 5:07 PM, Ben Chess wrote: > >> On Jul 8, 2011, at 8:24 PM, Michael Bayer wrote: >>> OK so you're caching. Actually when I worked with caching a lot I found >>> that I was looking for the objects to exist without their related >>> collections, then I'd use the Beaker recipe so that the collections etc. >>> were cached separately as they were lazy loaded. It allowed the cache to >>> contain individual collections of things more discretely, rather than >>> several large trees tailored towards some specific loading scenario. The >>> more granular level collections allowed the retrieval over memcached to not >>> spend time loading things that weren't needed for a particular view. >> >> Okay, but let's not get off topic. How the results are cached has nothing >> to do with the fact that eagerload just isn't reliable. If I eagerload a >> few objects in, I'd expect that that no further SQL queries will be >> necessary to use those objects. That's currently not the case. > > I'd argue it's on topic as the behavior of SQLAlchemy is always optimized to > real world usage. This is a potentially huge, performance-impacting, > behavior-changing, stability-impacting change, so my desire to define the use > case here very specifically, and absolutely rule out other, simpler ways to > accomplish the use case, is pretty important. The ORM is very tailored > towards a rich interaction between objects and an ongoing transaction. > When I get these requests for highly tailored "detached" behavior, my goal is > to not disrupt the primary usage paradigms.
We cache these objects together specifically because they're used together. The denormalization of these rows is the big win. To cache them all separately means 10x the number of memcache gets and 10x the number of invalidations when things change. Consistency is also a concern so we'd need some way to make the memcache updates atomic. These updates would also take 10x the number of SQL queries because we can't rely on eagerload to do its job. I'm open to alternatives if you have a better idea. Ben -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. 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.
