You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
I've considered two options:
object
is already accessible here, so the ID also can't be used to create a unique "path_cache_key".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?
The text was updated successfully, but these errors were encountered: