Code

Opened 9 years ago

Closed 6 years ago

#590 closed enhancement (wontfix)

Hinting cache from views (vary cache time by object age)

Reported by: eugene@… Owned by: nobody
Component: Core (Cache system) Version:
Severity: trivial Keywords: cache
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Currently cache system uses rather simple way to specify expiration time: it is either some global value for per-site cache, or decorator's parameter for per-view cache. In reality in many cases it depends on content.

For example, any news-oriented site (newspaper, blog, message board, ad place, and so on) rarely (if ever) changes archived articles. It is normal to go and change a recent article --- some typos, omissions, and recent development may warrant updates. In this case it makes sense to set hours (days? weeks?) for old articles, and few minutes for recent ones. Possibly some gradations would be required depending on age of underlying document.

It is quite possible to find other influences on cache item expiration time: tags, trends of user's activity, and so on.

I propose to add a property to response object, which will indicate the desired expiration time. It can be set by view methods (or some custom middleware). If it is set, it's used by cache middleware. If not, existing mechanism is used.

This change doesn't break existing code. Required code changes are rather trivial --- existing cache middleware uses similar mechanism already (request object is used instead of response object). That's why I don't submit a patch this time --- it boils down to invention of right name for the property. I trust you guys would be far more consistent than me.

Attachments (0)

Change History (2)

comment:1 Changed 7 years ago by Simon G. <dev@…>

  • Keywords cache added
  • Summary changed from Hinting cache from views to Hinting cache from views (vary cache time by object age)
  • Triage Stage changed from Unreviewed to Design decision needed

comment:2 Changed 6 years ago by jacob

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

Seems this is better done with more granular caching inside the view itself.

Add Comment

Modify Ticket

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


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

 
Note: See TracTickets for help on using tickets.