Opened 7 years ago

Closed 6 years ago

#3445 closed (wontfix)

all caching-related code should be collected into its own cache application

Reported by: Gary Wilson <gary.wilson@…> Owned by: nobody
Component: Core (Other) Version: master
Severity: Keywords:
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


There are various modules related to caching spread throughout the django tree. They should be collected into a "cache" package/application.

Attachments (1)

3445.diff (10.9 KB) - added by Gary Wilson <gary.wilson@…> 7 years ago.
Moved cache related modules into a cache package

Download all attachments as: .zip

Change History (8)

comment:1 Changed 7 years ago by Gary Wilson <gary.wilson@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

comment:2 Changed 7 years ago by mtredinnick

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.

comment:3 Changed 7 years ago by Gary Wilson <gary.wilson@…>


comment:4 Changed 7 years ago by Gary Wilson <gary.wilson@…>

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.

Changed 7 years ago by Gary Wilson <gary.wilson@…>

Moved cache related modules into a cache package

comment:5 Changed 7 years ago by Gary Wilson <gary.wilson@…>

  • Has patch set


  django/core/cache => django/cache
  django/middleware/ => django/cache/
  django/utils/ => django/cache/
  django/views/decorators/ => django/cache/

comment:6 Changed 6 years ago by jacob

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 Changed 6 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

After talking with Malcolm, it just doesn't see like this is worth the breakage.

Add Comment

Modify Ticket

Change Properties
<Author field>
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.