Using Quarkus cache directly instead of CacheResult

[sandip-stats]

HI,

This is with reference to 'https://quarkus.io/guides/cache'. I see that the cache can be used directly as also has been mentioned in the blog.

@CacheName("my-cache")
 Cache cache;

 public Uni<String> getNonBlockingExpensiveValue(Object key) { 
     return cache.get(key, k -> { 
         /*
          * Put an expensive call here.
          * It will be executed only if the key is not already associated with a value in the cache.
          */
     });
 }

I was wondering if their is a way I can embed a DB call (using reactive style via panache) in a non blocking way, in the placeholder . The code below which works but in a blocking manner is ...

@CacheName("my-cache")
  Cache cache;

@Blocking    
public Uni<myObject> getNonBlockingExpensiveValue(Object key) { 
      return cache.get(key, k -> { 
         return DBservice.findById(k).await().atMost(Duration.ofSeconds(10));
      });
  }

Do note thatDBservice.findById(k)is returning a Uni using the 'active record pattern'.

Any suggestion would be of great help.

[quarkus-bot[bot]]

/cc @gwenneg

[gwenneg]

Hi @sandip-stats.

Mixing async calls based on Uni with the programmatic caching API is not currently supported by quarkus-cache even though it is implemented already internally because of the annotations caching API. Here's how your code would look like if it was made available with the programmatic API:

    @Inject
    Cache cache;

    public Uni<Object> getNonBlockingExpensiveValue(Object key) {
        return cache.get(key, k -> UnresolvedUniValue.INSTANCE)
                .onItem().transformToUni(value -> {
                    if (value == UnresolvedUniValue.INSTANCE) {
                        return DBservice.findById(key)
                            .call(emittedValue -> cache.replaceUniValue(key, emittedValue));
                    } else {
                        return Uni.createFrom().item(value);
                    }
                });
    }

quarkus-cache stores the result of a Uni resolution and not the Uni itself. Because of that, we have to rely on a dummy value UnresolvedUniValue.INSTANCE if nothing's available in the cache for a given key. Then, after the initial Uni (the DB call in your case) has been resolved, the item it emitted is put in the cache, replacing the dummy value. All subsequent calls to the cache with the same key will immediately retrieve the value that resulted from the Uni resolution.

This isn't really user-friendly so I'm not sure it is a good idea to introduce that into the programmatic API considering that the annotations caching API provides an alternative to achieve the same goal in a much easier way.

[sandip-stats]

Hi @gwenneg

The use case i was looking at for which i was looking at this kind of pattern is as follows:-

Its a Graphql interface, with Postgres as the Datastore

Relationship
A -> one to many -> B -> one to many -> C
Am querying for all the elements of 'A' for which the output would be :

A : {
	"field of A" : "..."
	...
	...
	B : [
			{
				"field of B" : "..."
				...
			    ...
				C : [
					{
						"field of C" : "..."
						...
					},
					{
						...
						...
					}

				]
			},
			{
			  ...
			  ...
			  ...
			  C : [
				  {
				  		...
				  		...

				  },
				  {
				  		...
				  		...
				  }
			  ]
			},
			...
			...
		]
}

The Front end Code would be something like the following, the function making DB calls :

@Query(value = "getA")
public Uni<A> getA(@Name('id') Integer id){
	.... Query A via id...
        .... Build cache (region A) with Key - id
}

@Name("addB")
public Uni<List<B>> addB(@Source A a){
	.... Query B via A.id....
        ..... Build cache (region B) with Key - id
}

@Name("addC")
public Uni<List<C>> addC(@Source B b){
	.... Query C via B.A.id 
        .... Build cache (region C) with Key - id
        .... iterate over the results and keep returning List of C's for each B
}

The issue comes with regards to addC, as this will be called multiple times (= size of B).
In order to avoid multiple queries, i was querying via A's id and was planning on caching the result.

Do you see any other way of handling it.

[gwenneg]

Did you try using the @CacheResult annotation on addC? It feels like the annotations caching API should be enough to cache the data you're querying from the DB.

[sandip-stats]

Yes @gwenneg thats how i approached it first. The very first invocation of the getA() which inturn calls addB() and then multiple addC() call is making multiple calls to the DB. Post that things are fetched from the cache (i.e from second invocation onwards).

What i was trying to avoid is the multiple DB calls during the first time invocation itself.

[jie-huang]

@gwenneg
Your example with UnresolvedUniValue seems works. But, it like a work around instead of a solution.

How about to add an interface?
Uni<V> getUni(key, function<K, Uni<V>>)

TBH, I do not really understand current Uni<V> get(key, function<K, V>).
If a function is not a Uni (even it is time cost, e.g. a lot of calculation), there is no apparent benefit by making it to a Uni.

Thanks

[gwenneg]

Hi @jie-huang.

Cache#getAsync(K, Function<K, Uni<V>>) was recently added (see #30311) and will be available starting Quarkus 3.0.0 which is currently an alpha release (3.0.0.Alpha5). UnresolvedUniValue will be deprecated in that version and removed eventually.