Clear setting-dependant caches when settings are overridden (in tests)

[Aymeric Augustin]

r16237 introduced a setting_changed signal, triggered by the override_settings decorator / context manager.

However, Django doesn't use this signal to reset caches that depend on built-in settings. In the current state of thing, the signal is only usable is third-party code.

Is this a design choice or a bug?

Marking as release blocker since it's a major bug in a new feature.

[Aymeric Augustin]

We discussed this on IRC and determined that:

• this should be fixed eventually — override_settings doesn't reach its full potential until then
• this doesn't need to be fixed in 1.4 — override_settings is useful, even without this, and we don't want to make too intrusive changes at this point

[Aymeric Augustin]

It would be nice to add a note mentioning this limitation in the 1.4 docs.

[Aymeric Augustin]

In [17597]:

Clarified the fact that the signal_changed signal isn't used by Django itself (yet). Refs #17787.

[Aymeric Augustin]

#17744 is an instance of this problem, with MEDIA_ROOT.

[Aymeric Augustin]

#17882 has another use case.

[Claude Paroz]

Several settings are now using the setting_changed signal. I don't think it's useful to get this one open.

[Aymeric Augustin]

I'd like to review a few more settings :)

[Aymeric Augustin]

Also 2ddfcfbec6 should be reverted before closing this ticket.

[Ramiro Morales]

FYI,

Locale-related global state is now reset since 32a4df6c55f2efd020b7fbc44c858f61b07da17d (a fix for #18395). See ​https://github.com/django/django/blob/master/django/test/signals.py

[Aymeric Augustin]

We're in an inconsistent state right now. Some settings are properly reset and others aren't; the docs still say that the signal isn't used.

I don't think I'm going to work on this exhaustively.

We still have to document the new behavior before the next release. At worst, open django/tests/signals.py, make a list of settings that are reset, and put that in the docs...

[Claude Paroz]

Replying to aaugustin:

We're in an inconsistent state right now. Some settings are properly reset and others aren't;

Let's create tickets for each setting unproperly reset. But auditing the code to relate settings with global cached variables might be something hard. I'm afraid only bugs will reveal those.

the docs still say that the signal isn't used.

We still have to document the new behavior before the next release. At worst, open django/tests/signals.py, make a list of settings that are reset, and put that in the docs...

I'm attaching a patch for updating the docs.

[Claude Paroz]

Update override_settings docs

[Claude Paroz]

I just committed one more in c7f44ae085df3a270aa998cdedb56f36900cb9ef (TEMPLATE_LOADERS). Let's not forget it when committing.

[Claude Paroz <claude@…>]

In fc2681b22b120a468607c6aeb06163d8e5dbf897:

Fixed #17787 -- Documented reset caches by setting_changed signal

[Claude Paroz <claude@…>]

In c5da577b9e394b3b4696e4f4ca495c82951b6678:

[1.5.x] Fixed #17787 -- Documented reset caches by setting_changed signal

Backport of fc2681b22 from master.