Set expiry time on "set"

[sqlalchemy-bot]

Migrated issue, originally created by Mark (mhall)

It would be nice if the //region.set// method accepted an optional //expiration_time// parameter, just as the //get_or_create// method allows for.

[sqlalchemy-bot]

Michael Bayer (zzzeek) wrote:

the expiration time isn't stored with the value so this wouldn't really be possible. expiry time is always in terms of the region/getter.

[sqlalchemy-bot]

Mark (mhall) wrote:

Ah right. Fair enough. Perhaps a note to that effect in the docs might be useful.

[sqlalchemy-bot]

Michael Bayer (zzzeek) wrote:

that's in [[https://bitbucket.org/zzzeek/dogpile.cache/changeset/0237d06a2a24bbc94f74d6b69f182348b7e1e2b1|0237d06a2a24bbc94f74d6b69f182348b7e1e2b1]]. I can see maybe we'd allow storage of expiry time in the cache as an option at some point, though I'm not sure what the advantage to that is. I guess it depends on how the cache is being used.

I sort of thought Beaker wasn't storing the expiration time but it looks like at some point it was changed to do so, but this might be because of beaker's slightly more out of control API which allows any kind of parameter to be sent anywhere.

Not storing the expiration time means you can change it without rewriting data in the cache. If you did change it locally, then you got a value in the cache with the old expiration time, which one would you honor ? it doesn't make sense to honor the one that's in the cache if you've configured a different time, so then it becomes why bother storing it in the cache at all if you always have the local one.

[sqlalchemy-bot]

Changes by Michael Bayer (zzzeek):

• changed status to closed