With spring boot version 2.1.4, I found below code which doesn't serve as prefix, instead it overrides the cacheName passed in. Is it a bug? or it is by design?

public RedisCacheConfiguration prefixKeysWith(String prefix) {
    Assert.notNull(prefix, "Prefix must not be null!");
    return computePrefixWith((cacheName) -> prefix);
}

Is it support to be below code ?

public RedisCacheConfiguration prefixKeysWith(String prefix) {
    Assert.notNull(prefix, "Prefix must not be null!");
    return computePrefixWith((cacheName) -> prefix + ":" + cacheName + "::");
}

Comment From: snicoll

org.springframework.data.redis.cache.RedisCacheConfiguration is part of Spring Data. I suggest to build a small sample that reproduces what you've described as I am not sure I understood.

The issue tracker of Spring Data Redis is on Jira.

Comment From: markfredchen

@snicoll Sorry I didn't find "Issues" tag in Spring Data. Here is a simple demo I created: git@github.com:markfredchen/redis-demo.git

@SpringBootApplication
@EnableCaching
public class RedisDemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(RedisDemoApplication.class, args);
    }

    @Bean
    public CommandLineRunner redisDemoRunner(FooService fooService) {
        return args -> {
            fooService.getById(1000L);
            fooService.getById(2000L);
        };
    }

}

@Data
@AllArgsConstructor
class Foo implements Serializable {
    private Long id;
    private String foo;
}

@Service
@CacheConfig(cacheNames = "FOO")
class FooService {
    @Cacheable()
    public Foo getById(Long id) {
        return new Foo(id, RandomStringUtils.randomAlphabetic(6));
    }
}

application.properties

spring.cache.redis.key-prefix=REDIS_DEMO

Result

127.0.0.1:6379> FLUSHALL
OK
127.0.0.1:6379> KEYS *
(empty list or set)
127.0.0.1:6379> KEYS *
1) "REDIS_DEMO1000"
2) "REDIS_DEMO2000"
127.0.0.1:6379>

The expected result should be - REDIS_DEMO:FOO::1000 - REDIS_DEMO:FOO::2000

If I remove the config in application.properties, the result is

127.0.0.1:6379> FLUSHALL
OK
127.0.0.1:6379> KEYS *
(empty list or set)
127.0.0.1:6379> KEYS *
1) "REDIS_DEMO1000"
2) "REDIS_DEMO2000"
127.0.0.1:6379> KEYS *
1) "FOO::1000"
2) "REDIS_DEMO1000"
3) "REDIS_DEMO2000"
4) "FOO::2000"
127.0.0.1:6379>

Comment From: markfredchen

created JIRA issue DATAREDIS-975

Comment From: mahesh1247

DO we have any estimate on the fix. we are also facing the same issue.

Comment From: OrangeDog

Also filed as DATAREDIS-1041. There's no sign of the Data team wanting to change anything.

You may also open a ticket for boot to discuss if it makes sense to maybe switch to computePrefixWith.

@snicoll can that be here or a separate ticket? The current implementation of spring.cache.redis.key-prefix is mostly useless at the moment.

The proposed change would be to createConfiguration:

if (redisProperties.getKeyPrefix() != null) {
    String prefix = redisProperties.getKeyPrefix();
    config = config.computePrefixWith(cacheName -> prefix + cacheName + "::");
}

Comment From: snicoll

The current implementation of spring.cache.redis.key-prefix is mostly useless at the moment.

It's just delegating to RedisCacheConfiguration#prefixKeysWith so the implementation is on the Spring Data side, not in Spring Boot. Let's keep the conversation on the Spring Data issue for now.

Comment From: snicoll

reopening Now that the Spring Data issue has been fixed and they offer an alternative that takes care of the cache name.

Comment From: snicoll

Arguably this is a bug but changing the key we generate in a maintenance release is a bit brutal