On Jul 9, 2011, at 5:07 PM, Ben Chess wrote: > On Jul 8, 2011, at 8:24 PM, Michael Bayer wrote: > >> On Jul 8, 2011, at 6:17 PM, Ben Chess wrote: >> >>> Hmm, bummer. >>> >>> We're pretty dependent on detached mode. We eagerload a bunch of >>> things for the purposes of storing them in memcache, and things don't >>> go well when they're not fully traversable. >> >> 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. > I experimented a bit with trying to to intelligently recurse down the paths > defined by the eagers and see if there are any unloaded objects. I didn't > quite know what to do in the case of lists. It felt like I was going to have > to re-write a lot of things that the populators already do. > > My proposal: If there are eagers with paths longer than 1 attribute, always > re-populate that attribute. I'd rather have correctness over performance. > Or at least have the option. Here's my patch: http://pastebin.com/j8pakaLP OK the patch would have to take into account all kinds of eager loading, such as subquery loading, others. Augmenting the "unloaded" collection is the key of course. Its very likely this would have to be an option, else existing apps might be impacted. If that's the case, what sucks about that is, you're probably the only person who will ever understand what the option does. It depends on how it comes out. -- 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.
