Opened 12 years ago
Closed 12 years ago
#19334 closed Cleanup/optimization (duplicate)
Caching the current Site object into cache backend
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | contrib.sites | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
As it is described here current site object is cached.
I was very surprised, when it turned out, that this object is cached into sites.models.SITE_CACHE dictionary
I think, that Django should use the same cache engine everywhere. Caching into global objects could produce problems that are very hard to diagnose. Also, it is much easier to have only one interface to flush the cache.
I propose to use standard cache interface here. I could provide the patch, if you think it is reasonable.
Change History (4)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
As Aymeric points out, there's no guarantee that a cache backend is available.
The real problem here is that there is global state -- and while I'll agree that this is a problem, it's not a problem we fix by moving to a different store to hold that global state.
I'm going to mark this wontfix. I'll completely agree that it would be a good idea to remove the global state; however, this is really a small part of a much bigger architectural problem.
comment:3 by , 12 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
This should more properly be closed as a dupe of #15894. Nobody there has yet objected that not everyone has a cache configured. This is so extremely broken in a multiprocess environment that it deserves fixing, in my opinion.
comment:4 by , 12 years ago
Resolution: | → duplicate |
---|---|
Status: | reopened → closed |
Not everyone has a cache configured.