-
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?
@@ -119,17 +121,17 @@ public static RedisCacheConfiguration defaultCacheConfig(@Nullable ClassLoader c | |||
|
|||
private final ConversionService conversionService; | |||
|
|||
private final Duration ttl; | |||
private final Supplier<Duration> ttlProvider; |
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
|
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
Fix issue: #1433 .
Give users a chance to change the
ttl
dynamically and give them the flexibility to do so.