-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Allow to dynamically provide TTL configuration #2587
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using a context-less supplier doesn't add much value here. I could well think of a case, where the TTL could be computed from the actual object.
How about a design of a TTL function (Function<Object, Duration>
) where the object argument is provided by the actual cache value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A Supplier
doesn't make much sense as it just defers the decision on TTL without adding much contextual value.
Hi @mp911de , I agree with that we should provide some context for user to get the ttl
and I did the updates.
And the changes:
- For now I provide the original
key
andvalue
to users instead ofcreateAndConvertCacheKey
. - About the
public Duration getTtl() {}
for backward compatibility, I user theObject.class
as the default key instead.
Thank you for your contribution. That's merged and polished now.
We now support a TtlFunction to compute the time to live for cache entries. Closes spring-projects#1433 Original pull request: spring-projects#2587
Uh oh!
There was an error while loading. Please reload this page.
Fix issue: #1433 .
Give users a chance to change the
ttl
dynamically and give them the flexibility to do so.