Fixed #22085 - Added a feature that allows the Cache settings argument to be None, for "no timeout". #2365

Closed
wants to merge 9 commits into
from

Conversation

Projects
None yet
2 participants
@zedr
Contributor

zedr commented Feb 23, 2014

Django 1.6 introduced a feature that allows the passing of None as the timeout argument when setting a cache key, using the Django caching framework. This is interpreted as "no timeout", so the cache object will set a non-expirable key as the default, unless a different value for the timeout is passed.

However, if the TIMEOUT was set in the settings file, the default timeout was still 300 seconds.

Ticket #22085 was opened to address this, and was accepted as a new feature.

This fix implements the feature, and adds four new tests specific to this case.

To set a never-expiring timeout for cache keys as the default behaviour, simply define the CACHES setting in this way:

CACHES = {
    "default": {
        # define the backend here...

        # set the timeout to None, meaning "no timeout".
        TIMEOUT = None
    }
}

Now, by default behavior of the Cache instances will be to set non-expiring keys ("cache forever").

For more information, see ticket: https://code.djangoproject.com/ticket/22085

zedr added some commits Feb 23, 2014

zedr
Fixed #22085 - Add a feature for setting non-expiring keys as the def…
…ault.

This feature allows the default `TIMEOUT` Cache argument to be set to `None`,
so that Cache instances can set a non-expiring key as the default,
instead of using the default value of 5 minutes.

Previously, this was possible only by passing `None` as an argument to
the set() method of objects of type `BaseCache` (and subtypes).
zedr
Removed the import of `DEFAULT_CACHE_ALIAS` that redefines a previous…
… import

The GetCacheTests test case import the constant `DEFAULT_CACHE_ALIAS`
inside one of its test methods, redefining a previous import. Removing
this second import does not break the test.
zedr
Enhance fix for #22085: update the cache documentation to mention the…
… possibility of using as the default timeout
@zedr

This comment has been minimized.

Show comment
Hide comment
@zedr

zedr Mar 4, 2014

Contributor

I've updated the pull request with the relative items for the documentation and the release notes.

Contributor

zedr commented Mar 4, 2014

I've updated the pull request with the relative items for the documentation and the release notes.

docs/releases/1.7.txt
@@ -437,6 +437,12 @@ Cache
thread-safe any more, as :data:`django.core.cache.caches` now yields
different instances per thread.
+* Defining the :setting:`TIMEOUT` argument of the CACHES setting as ``None``

This comment has been minimized.

@bmispelon

bmispelon Mar 4, 2014

Member

Use :setting:CACHES``, but simply TIMEOUT (the :setting: thingy makes Django autolink the the reference docs).

@bmispelon

bmispelon Mar 4, 2014

Member

Use :setting:CACHES``, but simply TIMEOUT (the :setting: thingy makes Django autolink the the reference docs).

This comment has been minimized.

@bmispelon

bmispelon Mar 4, 2014

Member

My bad, you can actually use :setting:TIMEOUT ``.

@bmispelon

bmispelon Mar 4, 2014

Member

My bad, you can actually use :setting:TIMEOUT ``.

@zedr

This comment has been minimized.

Show comment
Hide comment
@zedr

zedr Mar 4, 2014

Contributor

I made the suggested modifications.

Contributor

zedr commented Mar 4, 2014

I made the suggested modifications.

- seconds (5 minutes).
+ seconds, to use for the cache. This argument defaults to ``300`` seconds (5 minutes).
+
+ .. versionchanged:: 1.7

This comment has been minimized.

@bmispelon

bmispelon Mar 4, 2014

Member

I think versionadded might be more appropriate here.

@bmispelon

bmispelon Mar 4, 2014

Member

I think versionadded might be more appropriate here.

@@ -363,9 +363,13 @@ Each cache backend can be given additional arguments to control caching
behavior. These arguments are provided as additional keys in the
:setting:`CACHES` setting. Valid arguments are as follows:
+

This comment has been minimized.

@bmispelon

bmispelon Mar 4, 2014

Member

I don't think the extra newline is needed.

@bmispelon

bmispelon Mar 4, 2014

Member

I don't think the extra newline is needed.

@@ -437,6 +437,12 @@ Cache
thread-safe any more, as :data:`django.core.cache.caches` now yields
different instances per thread.
+* Defining the :setting:`TIMEOUT <CACHES-TIMEOUT>` argument of the CACHES setting as ``None``

This comment has been minimized.

@bmispelon

bmispelon Mar 4, 2014

Member

Can you link CACHES to the appropriate :setting: too?

@bmispelon

bmispelon Mar 4, 2014

Member

Can you link CACHES to the appropriate :setting: too?

docs/releases/1.7.txt
+ will set the cache keys as "non-expiring" by default. Previously, it was
+ still being set to 300 seconds, although explicitly passing ``None`` to the
+ ```set()``` method of a subtype of
+ :class:`django.core.cache.backends.base.BaseCache` works as intended.

This comment has been minimized.

@bmispelon

bmispelon Mar 4, 2014

Member

Is that link working when you build the docs? I can't find the reference documentation for caches so you might need to just use double backticks (django.core.cache.backends.base.BaseCache).

@bmispelon

bmispelon Mar 4, 2014

Member

Is that link working when you build the docs? I can't find the reference documentation for caches so you might need to just use double backticks (django.core.cache.backends.base.BaseCache).

@bmispelon

This comment has been minimized.

Show comment
Hide comment
@bmispelon

bmispelon Mar 4, 2014

Member

The patch applies, but there's a warning about trailing whitespace:

$ git apply 2365.patch
2365.patch:316: trailing whitespace.
  If the ``TIMEOUT`` is set to ``None``, the cache keys will never expire. 
warning: 1 line adds whitespace errors.
Member

bmispelon commented Mar 4, 2014

The patch applies, but there's a warning about trailing whitespace:

$ git apply 2365.patch
2365.patch:316: trailing whitespace.
  If the ``TIMEOUT`` is set to ``None``, the cache keys will never expire. 
warning: 1 line adds whitespace errors.
zedr
Amended the fix for #22085 with minor edits, removing the whitespacin…
…g and using the correct amount of backticks
@zedr

This comment has been minimized.

Show comment
Hide comment
@zedr

zedr Mar 4, 2014

Contributor

I have removed the trailing whitespace character.

Regarding the link to the django.core.cache.backends.base.BaseCache: the syntax is correct, but I assume the link isn't built because it the association with the documentation for the class isn't made anywhere by Sphinx.

Any advice on this?

Contributor

zedr commented Mar 4, 2014

I have removed the trailing whitespace character.

Regarding the link to the django.core.cache.backends.base.BaseCache: the syntax is correct, but I assume the link isn't built because it the association with the documentation for the class isn't made anywhere by Sphinx.

Any advice on this?

@bmispelon

This comment has been minimized.

Show comment
Hide comment
@bmispelon

bmispelon Mar 4, 2014

Member

Yes, the syntax is correct but as you say, the link is broken because BaseCache is not documented anywhere in our documentation.

I see two ways you can fix this:

  1. Add reference documentation for BaseCache
  2. Don't use a link here, but a simple double-backtick quoting.

While option 1) might be nice, it's probably a lot of work and out of the scope of this ticket so I'd sugest going with option 2 (if you grep the documentation for BaseCache, you'll find that other parts of our documentation do this already).

Member

bmispelon commented Mar 4, 2014

Yes, the syntax is correct but as you say, the link is broken because BaseCache is not documented anywhere in our documentation.

I see two ways you can fix this:

  1. Add reference documentation for BaseCache
  2. Don't use a link here, but a simple double-backtick quoting.

While option 1) might be nice, it's probably a lot of work and out of the scope of this ticket so I'd sugest going with option 2 (if you grep the documentation for BaseCache, you'll find that other parts of our documentation do this already).

@zedr

This comment has been minimized.

Show comment
Hide comment
@zedr

zedr Mar 4, 2014

Contributor

I have changed the formatting to just use the double backticks.

Contributor

zedr commented Mar 4, 2014

I have changed the formatting to just use the double backticks.

@bmispelon

This comment has been minimized.

Show comment
Hide comment
@bmispelon

bmispelon Mar 4, 2014

Member

I squashed everything together, tweaked the docs a bit and merged it in 6fe22b3.

Thanks!

Member

bmispelon commented Mar 4, 2014

I squashed everything together, tweaked the docs a bit and merged it in 6fe22b3.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment