FWIW, I'm interested in this approach. I haven't had time to poke at the design, but wanted to at least give some indication of interest since the thread's been quiet.
On Dec 6, 2007 4:46 PM, David Cramer <[EMAIL PROTECTED]> wrote: > > read this first: > http://www.davidcramer.net/code/61/handling-cache-invalidation.html > > The goal is to create a cachedmodel, which relies on a completely > different set of routines. All calls to this model, whether it be a > foreignkey lookup, an objects call, or a JOIN on it's table (inside > the ORM), would be swapped out with cache calls. These cache calls > would fall back on the default ORM/QuerySet, but just for filling it's > cache. > > An example usage of my proposal (no in any serious depth): > > http://www.pastethat.com/?3k2kW > > You would be able to pull all of these keys, via the cache, or not, > because you have a reference to the model + the primary key available. > > Invalidation would be handled by simply changing the save/delete > methods on the CachedModel. > > I'm interested in anyones thoughts or similar implementations. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
