On Dec 13, 2007 11:14 AM, David Cramer <[EMAIL PROTECTED]> wrote: ... > > 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. > > If you're talking about actual written SQL inserts, then no. Our > methodology is that if the ORM can't handle it, fix the ORM. We want > to use the ORM for everything so that we actually don't run into > problems like this, and we can, in fact, handle all database calls and > caching with an underlying wrapper.
Sorry, I'll try to illustrate with an example. If you have a cached queryset with articles [a,b,c], and an article d is saved (which *would* satisfy the queryset if it were re-run), with the current idea, the cached queryset will continue returning [a,b,c] until the queryset times out, right? I think that's an OK approach (for many applications) to avoid the complexity of the dependency graph; any robust dependency graph implementation will, I think, end up implementing a significant subset of a database in memory. (SQLAlchemy has a crazy amount of code for this sort of thing.) ...Perhaps IRC or chat would be good here? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
