> > We briefly discussed adding row-level dependencies (this key is > > dependent on x, y and z keys. It would be handled by storing an extra > > object in memory that stored the dependencies for the object. A simple > > reverse mapping if you will. > > The intention here would be to handle inserts affecting cached lists > of object keys? This would be if you had, let's say, (and this is a bad example), an Article, that has a dependency of a User. If the article, or the user were changed, then both of those caches would flush.
A better use-case would be model level dependencies. So if you had a list of "new articles" you could set a dependency for object creation on the article model and that cache would be wiped each time that happened. > Anyway, responding to your blog post: > " > Removing objects is also fairly simply. When we are polling for our > list of references, we're going to need to see what's missing. When we > find missing objects, we try to get them (query the database). If they > fail, our cache is no longer valid. Easy, ya? > " > > If I follow, you mean that if any key in the cached list of object > keys is missing, then the individual objects are requested; if that > fails, the object key is removed from the cache list. Yeah? The > bit here doesn't do that, but you'd like to?http://www.pastethat.com/?weBZo Right. The code in the paste is actually our current CacheManager code and doesn't reflect any relation to CacheModel, but the idea is that it would. We would simply handle overriding data getting method to grab the data from the cache, if the cache failed, we'd attempt the db, if the db failed we'd raise some exception to tell our cache that it's invalid. > Separately, I imagine Curse has done a fair bit of ORM hacking; have > you looked at the queryset-refactor branch? It'll make some of this > easier, and will change a fair bit of the implementation. Do you plan > on accepting trunk after qs-rf lands? I'm planning on moving forward > w/ qs-rf (on the GIS branch), but would like to use this, too. We actually want to get caught up to trunk. We're still pre-unicode and it's causing a lot of problems. qs-rf is something I myself am very looking forward to getting in. (It means there will be no more excuses to get all my ORM additions in :P) > Since inserts are undetected by the cache in the basic proposal, are > you accepting only short timeouts? I imagine with your traffic, even > small windows of caching have big benefits. I guess the per-manager > timeout thresholds allow you to tune to different levels of staleness > based on the query purpose. If you're talking about actual written SQL inserts, then no. Our methodology is that if the ORM can't handle it, fix the ORM. We want to use the ORM for everything so that we actually don't run into problems like this, and we can, in fact, handle all database calls and caching with an underlying wrapper. However, the timeout thresholds would be on things such as "new articles" where we don't care if it's out of date for 5 or 10 minutes. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
