Here's some code that's been started -- I know you're interested in this Adrian :)
http://www.pastethat.com/?weBZo This pulls in 2 different things that we've worked on: CachedForeignKey (little bits of it), and CacheManager (which is what brings in CachedQuerySet as well). This is just a quick write up the basic CachedModel (which in no way will work w/o modifying Django). It should give a general of the idea. On Dec 6, 2: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 -~----------~----~----~----~------~----~------~--~---
