On Jul 9, 2011, at 8:24 PM, Ben Chess wrote: > > 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.
You have on your side that the proposed behavior does seem like its probably more correct. I have a patch forthcoming that does the basic idea but I'd need to think of some more tests, consider how / if it might be optional, etc. > > 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. > -- 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.
