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). Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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.
