Fixed #36830 -- Stored the cache alias on cache backend instances. - #20469

i'm unsure how i should write the release note
should i move the note to the breaking changes section?

📊 Coverage Report for Changed Files

-------------
Diff Coverage
Diff: origin/main...HEAD, staged and unstaged changes
-------------
django/core/cache/__init__.py (100%)
django/core/cache/backends/base.py (100%)
django/core/cache/backends/db.py (100%)
django/core/cache/backends/filebased.py (100%)
django/core/cache/backends/locmem.py (100%)
django/core/cache/backends/memcached.py (0.0%): Missing lines 16-17,148,181
django/core/cache/backends/redis.py (50.0%): Missing lines 162
django/core/management/commands/createcachetable.py (100%)
-------------
Total:   19 lines
Missing: 5 lines
Coverage: 73%
-------------

Note: Missing lines are warnings only. Some lines may not be covered by SQLite tests as they are database-specific.

For more information about code coverage on pull requests, see the contributing documentation.

Thank you for your contribution to Django! This pull request has one or more items that need attention before it can be accepted for review.

If you have questions about these requirements, please review the contributing guidelines or ask for help on the Django Forum.

I see this PR adds some deprecation, but I does the deprecation need to be documented anywhere else?

I see this PR adds some deprecation, but does the deprecation need to be documented anywhere else?

I think the built-in cache backend implementations—at least the BaseCache API shape—need to be treated as documented API subject to the usual deprecation policy. Because the docs say: "If you’re building your own backend, you can use the standard cache backends as reference implementations." Although Django users don't interact directly with these classes, developers of custom caches may. (They can't be considered strictly internal code.)

So yes, this would seem to need a release note explaining the changes needed in custom/third-party cache backends. (And an entry in docs/internals/deprecation.txt.)

i added a deprecation note in release notes
there doesn't seem to be a 6.2 entry in docs/internals/deprecation.txt so i assumed it doesn't need to be added there

rebased and squashed up to this point

(Also, Django is quite picky about commit messages: if you could capitalize the "S" in "Fixed #36830 -- stored the cache alias…" and change the message body to past-tense sentences, that will save the merger a step.)

Hi @amirreza-sf80, thanks for working on this! Adding alias to cache instances is a great improvement for parity with ORM and tasks.

A few observations and suggestions:

1. Import inconsistency in django/core/cache/__init__.py:
   django_file_prefixes is imported from django.utils.deprecation here, whereas in django/core/cache/backends/base.py it is imported from django.utils.warnings. We should import it from django.utils.warnings in both places.

2. Built-in backends constructor signatures:
   +1 to @medmunds' and @easherma's point regarding explicit alias=None over **kwargs for core backends (BaseDatabaseCache, RedisCache, LocMemCache, etc.). It avoids masking accidental typos and keeps signatures explicit for IDEs and type checkers.

3. Clarify the deprecation warning message in CacheHandler.create_connection:
   The check verifies whether the backend constructor accepts the parameter, so the message:
   "Cache backends must pass the 'alias' arg to BaseCache."
   might be clearer if rephrased as:
   f"Cache backend '{backend_cls.__name__}' must accept an 'alias' parameter."

4. Docs typo in docs/releases/6.2.txt:

   • "it's Subclasses" -> "its subclasses" (possessive and lowercase).
   • Capitalize "instances" to "Instances".

thank you
applied

explicit alias=None over **kwargs for core backends (BaseDatabaseCache, RedisCache, LocMemCache, etc.)

i think it should only be explicit in BaseCache
since BaseCache is the only class that uses this parameter
looking at other parts of django i see the same pattern applied, and i think it's helpful