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 -
Use Case -
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
timestamp_expiry. it possibly has an attribute for
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.