Allow cache configuration from file [DATAREDIS-938]

[spring-projects-issues]

Christoph Strobl opened DATAREDIS-938 and commented

Add option to read cache configuration from properties file.

The idea ist to have one global (default) configuration file redis-cache.properties

locked: [true, false]
ttl: 100
nullValues: [true, false]
keyPrefix: [simple, none]
serializer: [raw, java, string, json]
key.serializer : [raw, java, string, json]
value.serializer : [raw, java, string, json]

and additional ones for individual caches person.redis-cache.properties that can alter the defaults.

ttl: 200

---

Reference URL: spring-projects/spring-boot#19042

[spring-projects-issues]

Mark Paluch commented

That is rather an issue for Spring Boot. Our Redis cache doesn't seem to be used much without Boot. Shall we close this ticket?

[spring-projects-issues]

Mark Paluch commented

A good reason to provide file-based configuration by Spring Data Redis is that we would enable a uniform way to configure the cache API. By providing a schema we can validate the configuration and we don't rely on properties-driven development.

We would also align with the configuration mechanics of other Cache implementations. Note that there's a difference in what gets configured. While other Caches get fully configured (replication, eviction, sizing) by their config file, we have a config split. Eviction, replication, and sizing are configured directly in Redis. TTL, serializers, and such are client-side properties

[spring-projects-issues]

Christoph Strobl commented

As outlined by mark we moved the issue to backlog

[injae-kim]

PR: #3059

[christophstrobl]

Thank you @injae-kim for taking the time to work on this PR.
The original issue has been opened quite a while ago and Spring Boot already offers various configuration properties.

spring.cache.redis.cache-null-values=
spring.cache.redis.enable-statistics=
spring.cache.redis.key-prefix=
spring.cache.redis.time-to-live=
spring.cache.redis.use-key-prefix=

Since there's already some overlap we should consider if the existing configuration options are sufficient, what's missing and if, which project to extend.

[mp911de]

We discussed how to proceed here. Our cache comes from an API configuration side that is a lot simpler than what Infinispan or EhCache provide. We do not want to introduce a configuration file mechanism. Over time, it would us require supporting various dialects (XML, JSON, Yaml, …) and that is complexity we do not want to incorporate in our code.