On Tue, 2007-05-29 at 16:26 +0000, Paul Collier wrote: > > If I update o1 in some other part of the > > code, what assumptions are made about qs? > Hmm, yeah... I haven't focused enough attention on .cache_set() yet, > heheh. I was definitely just going to implement (1) first, and then > worry about something more advanced once I got to the "smart" > functionality (which I might just be making default behaviour now). At > some point I'll be writing a class with which cached queries register > so that pre/post_save signals can freshen the cache; that's should > lightweight enough to scale by itself, but to implement (3) I guess > it'd also have to track which PKs are present. I'm not really sure if > (2) is desirable.
I think your first option has the same problem that you spotted in number (3). Here's the possibly hidden problem with (1) -- which was "if o1 changes, invalidate all querysets that are cached containing o1" -- every time an object is saved, you have to work which cached querysets contain that object. This would be something like O(n*avg_size_querysets) if you don't come up with a fancy hash or bitmap or something to work out which are the dirty querysets. Not a bad first implementation, but check that it scales (I suspect the naïve approach will struggle to do so). I wouldn't worry about solving this up front, since it's a localised thing that you can tweak later once the bulk of the functionality is there, but it sounds like a fun problem to think about. Cheers, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
