Is there functionality to disable query caching?

[hnightingale1-r7]

Problem

Is there a way to bypass cubes query cache? I can see in the orchestrator query cache class
there is a forceNoCache flag for the QueryBody but it doesn't look like this is configurable from what I can see and is this something that could be made configurable?

To give context around why I am looking bypass this, is I am running multiple trino clusters which have a centralised cache and trino makes use of the open policy agent . Each request the query will be modified and filtered based on the permissions of the user.

I explored the avenue of adding a unique field to the security context to try force a new cachestore to be created on each request, to bypass the cache but wasn't successful in doing so.

Related Cube.js schema

queryRewrite: (query, context) => {
    if (!context.securityContext) {
      context.securityContext = {};
    }
    context.securityContext._cacheBuster = Date.now();
    return query;
  },

If there is any other suggestions on how I might achieve this that would be great or if this is something that could be potentially added?

Thanks in advance!

[igorlukanin]

Is there a way to bypass cubes query cache?

Not really. Cube has a multi-layered cache with the top layer being the in-memory cache. There's no way to bypass that one. However, I feel like this is not exactly relevant to your question.

I explored the avenue of adding a unique field to the security context to try force a new cachestore to be created on each request, to bypass the cache but wasn't successful in doing so.

Could you please explain what are you trying to achieve here? So, let's say Cube receives some request, serves it, and caches the result set. A couple of seconds later Cube gets the request with the same query and serves the results from cache. What is it in this scenario that is not good for you?

[hnightingale1-r7]

In my configuration the query is modified downstream at trino, using open policy agent. The query from the cube layer will be different once it reaches trino as open policy agent will transform it based on the users permissions. The issue being that if 2 users have different permissions and the query as far as cube is concerned is identical, it would hit the cache at the cube layer, but as this hasn't been modified by the open policy agent there is the risk of retuning data that isn't reflective of their permissions.

[igorlukanin]

How do you segregate users? How could Cube tell if the first query comes from user A and the second, identical query comes from user B?

If you have a way to tell one user from another, you need to implement multitenancy and let Cube maintain separate query queues and caches per tenant: https://cube.dev/docs/product/configuration/reference/config#context_to_orchestrator_id