jvanasco (jvanasco) wrote:

Ah, I missed this line and totally forgot about this behavior. Sorry for the noise!

'''
The dogpile.cache model does not store expiration times with the cached value, only the time that it was cached.
'''

As a frequent abuser of this library, I have a few suggestions:

A slightly modified version of Michael's serverside expiry above:

region.set(key, value)
region.actual_backend.client.expire(expiration_time) # new api to get around proxies, set expiry in redis
region.get(key, value, -1) # get key with no expiration time
You can create a custom backend that inherits from your current backend, and override the serialization / deserialization functions inset/get and set_multi/get_multi. This allows a developer to overwrite the internal invalidation timestamp during the serialization process, and substitute it with a value that always passes, fails or is a cache miss.

I actually do this often. If your backend is redis, I released a (fully tested, in production) backend that accepts custom dumps/loads functions: https://github.com/jvanasco/dogpile_backend_redis_advanced

ProxyBackends

Another method is the ProxyBackend. The values in get/set/multi are the CachedValue tuple with the expected value in the .payload attribute and a .metadata attribute with some specific information in it. I previously used these to alter the metadata expiration timestamp (as in #2), but switched to serialization function as I already moved to that concept.

I recommend against dealing with the raw Redis connection, as it can be a bit weird to properly correlate the values, serializers, etc. This gist I wrote the other day gives an overview of ways you can leverage the dogpile library into raw redis sets:

https://gist.github.com/jvanasco/7ee03c118885bd06e25b651e3139f606

set expiration date of individual items #124

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions