Multiple cache keys

[wvteijlingen-npo]

Question

Currently, SchemaConfiguration.cacheKeyInfo supports returning only a single CacheKeyInfo instance per object. As a result, each object can be cached using only one cache key. This works perfectly fine when reading cached objects using ApolloStore.withinReadTransaction { transaction in transaction.readObject(...) }

However, would it be possible to somehow support multiple cache keys per object?

I’ve experimented with a custom NormalizedCache that manually splits and joins the cache key strings to work around this limitation, but the approach feels like a hack and is not reliable at all.

Background

In our GraphQL schema some models have multiple unique identifiers. For example, a User has both an id and an urn. Due to legacy reasons, different parts of our application reference users by either id or urn.

Because the cache can only recognize one of these keys, we often have cache misses. This forces us to query the GraphQL endpoint even though technically the User object does exist in the cache.

[AnthonyMDev]

Thanks for the question @wvteijlingen-npo. There is currently no support for multiple cache keys. While you could create a cache key that combines both the id and urn, being able to look up the object by either one or the other is not supported.

Would it be possible for you to just fetch the id field along with the urn every where you are using it? Your application logic can use the urn, but if the id is fetched and used for cache normalization, it should still work properly.

---

We are working on a significant restructuring of the cache that will eventually allow you to run SQL queries against the cache based on the values of any individual fields, but that is a long ways out. However, I think there might be a better way to work around this in the 2.0 version, which is currently in beta.

2.0 allows you to write a custom CacheInterceptor that manages the cache read/writes for any GraphQLOperation. When writing these objects, you could create a separate persisted store that keeps track of the two keys of the objects. When doing reads for an operation that uses the urn, you could look up the id in that store and then read the object from the cache that way.

I'm not entirely clear on your exact use case, but I think something in that direction could work. You can create that custom store anyway you'd like. I'd probably hook into the SQLiteNormalizedCache and create an index table for the lookups in the same SQLite DB.

[AnthonyMDev]

I'm closing this issue due to inactivity. If this is still unresolved, feel free to provide more information and we can re-open this, or create a new issue.

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.