On Dec 8, 2007 10:29 PM, David Cramer <[EMAIL PROTECTED]> wrote: > > 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? 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 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. 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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
