On Thu, Jul 22, 2010 at 10:43 AM, Alex Gaynor <alex.gay...@gmail.com> wrote: > On Wed, Jul 21, 2010 at 9:41 PM, Russell Keith-Magee > <russ...@keith-magee.com> wrote: >> On Fri, Jul 16, 2010 at 6:54 PM, Carsten Reimer >> <carsten.rei...@galileo-press.de> wrote: >>> Hello, >>> >>> I am not quite sure if this is the right mailinglist but as long as my >>> remarks are about a core-component of django I hopefully chose the right >>> list. >>> >>> Dealing with cache-stuff in Django I realized that it seems to be impossible >>> to use a timeout=0 (which in terms of memcached meant that the item would >>> never expire unless it has to make way for new items due to memory >>> shortage). This is because even still in the most current trunk-version the >>> timeout is calculated (in >>> django.core.backends.memcached.CacheClass._get_memcache_timeout) as >>> >>> timeout = timeout or self.default_timeout >>> >>> where timeout is one of the parameters given to _get_memcache_timeout. >>> >>> So as long as timeout=0 always the default_timeout will be used. >>> Maybe this behaviour is intended to prevent memcached being filled up with >>> items that never expire. >>> In my opinion it may be better to enable developers to use the >>> timeout-values as intended by memcached (where 0 means no expiration at >>> all). >>> >>> So I would like to suggest to change the default value in all method >>> signatures of the memcached.CacheClass (and whereever it whould be >>> necessary) from 0 to None and to replace the line above by an if-clause as >>> >>> if timeout is None: >>> timeout = self.default_timeout >>> >>> This is not as elegant as the original version but now it would be possible >>> to use 0 as a timeout. >>> >>> If it would help I can try to open a ticket and provide a first path against >>> the current trunk. >> >> Sounds reasonable to me. This is a useful feature of the most useful >> caching backend library. It makes sense that we should support that >> feature, and the API approach you describe makes sense to me. >> >> If you open a ticket and provide a patch (with docs to describe the >> change), then this sounds like a good addition. >> >> Yours, >> Russ Magee %-) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to django-develop...@googlegroups.com. >> To unsubscribe from this group, send email to >> django-developers+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> >> > > FTR this exact same concept has been filed before, and closed wontfix > on backwards compatibility concerns (see Mike Malone's scaling Django > slides, where he's mentioned this several times).
Really? What concern? Can you point at a ticket discussion? Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
