Thanks for your response. We will investigate your suggestions for improving our design and look forward to seeing what you come up with for 0.7!
On Oct 20, 5:05 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: > On Oct 20, 2010, at 4:01 PM, Jasper K wrote: > > > > > Unfortunately I don't think the Session.expire(obj, ['attrname']) will > > work for our situation. If we ignore the problems relating to forward > > compatibility, would the above LazyStrategy work for what we are > > attempting to do without adversely affecting the internals of > > slqlachemy? > > the population mechanics are fairly simple so sure. > > > > > For future releases, what about providing different > > populate_existing() functionality with a query option that doesn't > > completely reset existing instances? > > Its a feature that doesn't make much sense from a transactional point of view > (that is, where things are either true to what's in the current transaction, > or they're not). It pretty much only applies exactly to your use case, the > "populate anything we get from SQL otherwise we dont care" approach. I'm > never a fan of adding flags that suit just one specific, very unusual, use > case. We then have to support it for all eternity long after anyone has > used it. As I implement the event model for 0.7 I'll try to consider what > kinds of events would allow plugging in of custom state management during a > load operation, such that exactly what you want to do is possible, but not an > explicit "flag" by itself. Ideally I'd like to ditch populate_existing() > entirely (will probably never happen). > > > > > Our way around this second problem is to override the Query.get > > functionality to ignore the populate_existing flag and check the > > identity map anyway. While this "hackiness" is something we would like > > to avoid, I suppose it is not altogether possible given the complexity > > of multiple user requirements! Maybe you have some ideas for how to > > improve this specific use case? > > I think the non-traditional approach to caching is at the core of the issue > here. With your system, you don't have a definitive point at which an > object becomes "stale". Its instead depending on usage context how > something becomes "stale" - that is, if the app happens to be just doing > get()s for a few hours, your data is now a few hours stale. If it happens to > do some queries, populate existing kicks in and those objects are "not > stale". This is a pretty sloppy approach to cache expiration. In this > case, you are specifically tracking change events so it seems pretty clear > that you'd want to just expire the objects in your "cache" session that are > being updated through a flush on the "user" session, or just populate their > state directly as updates are made - this is known as a "write through" > cache. You can do this > usinghttp://www.sqlalchemy.org/docs/orm/session.html#sqlalchemy.orm.attrib.... > Also, if you used a SQL caching approach with timed expirations like that > used in the Beaker example, then you'd really be saving a ton of SQL. I've > used that approach successfully to tune various web pages down to zero > queries on an as-needed basis. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@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.
