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.
e.g. - articles_article:1 has the object cache for the article with pk 1 - three other keys are reliant on mykey (which is actually using the row-level object cache, so its something like an article object) - articles_article:dependents:1 has key1,key2,key3 stored in it We would register these depencies in models (somehow, haven't went this far into it). All objects would still automatically gain deletion invalidation via the method described in the original post. One other problem that was noted that isnt documented, is storing select_related depths. So the cache key for lists would become (Model, (list, of, pks), (list, of, select, related, fields)) and then we'd know which ones we need to batch store in memory upon pulling from the cache. On Dec 7, 8:05 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote: > On 12/7/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote: > > > > FWIW, I'm interested in this approach. > > > Same here. I'm planning to look at this on Monday, but am very much > > interested. > > I haven't given any thought to how caching should work internally, but > this approach seems on par with how the external API should work > (interchangably with standard models, that is). Good luck! > > -Gul --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
