Hi everyone,
The annotations caching API from the quarkus-cache extension has been around for a while and since it was released almost 2 years ago, Quarkus users asked for a programmatic caching API multiple times.
Since #8631 already received quite a lot of comments, I'll try to make this discussion easier by summarizing below the main changes from that proposal. Before you continue reading this, I encourage you to read the
#8631 doc update which includes several code examples explaining how to use the new API.
Here's also a reminder of a few undocumented parts of the programmatic API that have already been merged a while ago:
- It is already possible to inject a
Cache bean (main branch link) in any CDI managed bean using the
@CacheName qualifier (main branch link) as shown in the #8631 doc update.
- Injecting the
CacheManager (main branch link) and then retrieving a Cache from its name is also possible already. This is also explained in the doc update.
However, in both cases the injected or retrieved cache cannot be used as-is because the Cache interface does not contain any method. This is where #8631 kicks in.
#8631 introduces the following methods in the
Cache interface (#8631 link):
public interface Cache {
String getName();
Object getDefaultKey();
<K, V> Uni<V> get(K key, Function<K, V> valueLoader);
Uni<Void> invalidate(Object key);
Uni<Void> invalidateAll();
<T extends Cache> T asSpecializedCache(Class<T> type);
}
As you can see in the new signatures, the programmatic API main operations are asynchronous and depend on Mutiny.
#8631 also introduces the
CaffeineCache interface which is meant to contain methods specific to the Caffeine caching provider which is currently the only available provider:
public interface CaffeineCache extends Cache {
Set<Object> keySet();
}
As I suggested
here, an alternative approach could consist in moving most of the Cache interface methods to the CaffeineCache interface:
public interface Cache {
<T extends Cache> T asSpecializedCache(Class<T> type);
}
public interface CaffeineCache extends Cache {
String getName(); // This could stay in Cache
Object getDefaultKey(); // This as well
<K, V> Uni<V> get(K key, Function<K, V> valueLoader);
Uni<Void> invalidate(Object key);
Uni<Void> invalidateAll();
Set<Object> keySet();
}
That approach would probably make things easier if we wanted to add a new caching provider to the extension while still supporting Caffeine.
Now here comes my question to you, dear Quarkus community. Is it worth merging #8631 (with or without changes) or should that PR simply be closed? It's been open for a very long time and it looks pretty much ready to me.
What do you think?
Gwenneg