Open
Description
Hey Dimitri,
I'm looking for some guidance. Currently I'm implementing the fragment cache in a rather large codebase. It's working well for most of our not so complex queries, but for queries using a Union we're (obviously) running into the Lookahead error.
I've been looking for ways to solve this without changing the cache key lookup implementation, but no luck so far.
A little context on the codebase and issue:
- We have thousands of GraphQL fields
- Some of these fields could be used in a Union
- It's not manageable to set up a "path_cache_key" and "query_cache_key" on all of them to prevent the lookahead error
I've considered two options:
- Dynamically adding a "path_cache_key" and "query_cache_key" to the fields that require this to work. However, in the GraphQL Field class where I can add this I don't have the context on wether or not this field is used from within a Union. So I cannot determine this. I don't believe the
object
is already accessible here, so the ID also can't be used to create a unique "path_cache_key". - Disabling caching on fields that hit a lookup error. I wasn't able to do this, with the same reason as above. Also, the error is being hit in the CacheKeyBuilder class, and I don't think that's the right layer to be bumping out of the "should we cache or not" behaviour.
It's been a couple of years since the Lookahead#selects? not matching fragment/type fields discussion and Add union support PR. Are you aware of any things that might have changed in this time that would make it easier to find a solution for the lookahead problem?
Metadata
Metadata
Assignees
Labels
No labels