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 using http://www.sqlalchemy.org/docs/orm/session.html#sqlalchemy.orm.attributes.set_committed_value. 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.
