A modern programming language that makes developers happier.

kotlinlang

we have a `CreateSomethingMutation` and a `SomethingQuery` (code in the thread) — they both return the same thing (semantically), but they're both different from each other in structure/arguments, which means this happens:
• `CreateSomethingMutation` is called and we cache its result
• `SomethingQuery` is then observed (cache only) but we then get a cache miss
our current workaround is to manually get the result from the mutation and add it to the cache as if it was the result of the query, and then everything works fine, but this seems like a common scenario so I thought I'd check if there's any better way to handle this (e.g. tweaking somehow the graphql structure?)

```mutation CreateSomethingMutation(
    $somethingInput: SomethingInput!
) {
    createSomething(somethingInput: $somethingInput) {
        something {
            ...SomethingFragment
        }
    }
}

query SomethingQuery($somethingId: String!) {
    something(somethingId: $somethingId) {
        ...SomethingFragment
    }
}```

Does the type returned by `something` have an id?

yes!

```fragment SomethingFragment on Something {
    id
    # other properties
}```

and do you have a corresponding `@typePolicy` ?

No `@typePolicy`, we have a `CacheKeyGenerator` that just returns the `id` of the object :face_with_peeking_eye:

that should work too.

What about a `@fieldPolicy` so the cache knows where to look for `something(somethingId: $somethingId)`?

I was just thinking about the same now. The truth is that I never got very deep into these directives, but it does look like something which might work. We'll test it out and get back, thanks! :smile:

peeking into the cache also helps understanding what's going on :slightly_smiling_face:

So, it _almost_ worked out of the box :tada:. The problem was that the default `FieldPolicyCacheResolver` was prepending the typename to the cache key. But like I was saying above, we have a `CacheKeyGenerator` that just returns the ID, without the typename prefixed (which I think it's unfortunate in retrospect, due to possible collisions), so we were getting exceptions like `com.apollographql.apollo.exception.CacheMissException: Object 'Something:SomethingId123' not found`. We just reimplemented our own `CacheResolver` that just joins the key args, skipping the typename prefix, and it all worked like a charm :sparkles:
Thanks for your prompt guidance as always! :slightly_smiling_face:

That makes a lot of sense! And for completeness sake, I'll add that with the new cache it's possible to configure weather cache ids are unique per service or not (to prefix with the type name or not). (<https://apollographql.github.io/apollo-kotlin-normalized-cache/migration-guide.html#typepolicycachekeygenerator|doc>)

We only have one service. But sometimes (very rarely though) we are bad with giving unique IDs to some objects :see_no_evil: It didn't cause any huge problem so far, but it's definitely a footgun in our project.