Opened 18 years ago
Closed 17 years ago
#3445 closed (wontfix)
all caching-related code should be collected into its own cache application
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Core (Other) | Version: | dev |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Design decision needed | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
There are various modules related to caching spread throughout the django tree. They should be collected into a "cache" package/application.
Attachments (1)
Change History (8)
comment:1 by , 18 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:2 by , 18 years ago
comment:3 by , 18 years ago
./django/core/cache/ ./django/views/decorators/cache.py ./django/utils/cache.py ./django/middleware/cache.py
comment:4 by , 18 years ago
The Object-level caching Summer of Code project makes an even stronger case for a cache package. The author has proposed adding a caching app to contrib, but I suggest we put everything into one cache app.
comment:5 by , 17 years ago
Has patch: | set |
---|
Renames:
django/core/cache => django/cache django/middleware/cache.py => django/cache/middleware.py django/utils/cache.py => django/cache/utils.py django/views/decorators/cache.py => django/cache/decorators.py
comment:6 by , 17 years ago
I agree that the four different "*.cache" modules are silly, but this'll break a lot of user code just for a bit of cleanup. So here's the $1 million question: is the code churn and renaming "worth" the cleanup?
comment:7 by , 17 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
After talking with Malcolm, it just doesn't see like this is worth the breakage.
Gary, can you provide a few more details on where the scattering is? It sounds like you already know the details. Not easy to make a decision on this without more information.