idea for time issues/features

Migrated issue, originally created by jvanasco (jvanasco)

I came up with a use-case and idea that might tie together a few existing tickets.

It also might be a terrible idea.

Existing Tickets -

https://bitbucket.org/zzzeek/dogpile.cache/issue/37/expose-cache-age
https://bitbucket.org/zzzeek/dogpile.cache/issue/45/update-expiration-time-on-get

Use Case -

Given:

A) We have some "write" operations that are more frequent on some objects than others.
B) Our objects can be expensive to generate
C) We want to balance performance and clarity of code

Two options come to mind:

1. use multiple cache keys: high-write area, low-write area
2. use a single object, update it

The first option can be less-readable

The second option has the caveat that writing will extend the cache expiry.

The general idea I have is this:

get_raw returns a CacheHit object that has attributes for payload and timestamp_expiry. it possibly has an attribute for timestamp_last_update.

CacheHit (or dogpile) has a method for soft_update -- which will set a modified payload without updating the expiry. alternatively, a new expiry time could happen as well.

This would allow people to keep the original expiry time ( let's say 10 minutes ) but have the ability to "update" the value of the payload within that time. They payload would still expire in 10minutes ( unless explicitly extended ).

In the use-cases of comments and surveys, this might allow a developer to increment the 'count' of respondents many times over the span of a minute... yet still require a sync to the backend datastore every 10 minutes.

Start by reading the linked tickets about exposing cache age and updating expiration on get, then trace the existing get_raw behavior and cache-hit representation. Clarify whether CacheHit should expose payload and expiry, whether last-update metadata is needed, and how soft_update should preserve or change expiry. Done means the API and expiry semantics are agreed and covered by tests.