I know it's undesirable, but I have BaseObject and ObjectThatUsuallyInheritsFromSomeBaseObjectUnlessOverwritten. However, the type name of the second one has never been exposed yet (I assume this one also may fix it).

So now, when I get the inherited object with unmerged properties, that would overwrite the cache, and using that in a different place will have the wrong display (for example undefined name, since it's inherited).

I thought if I could add no-cache when I fetch it with unmerged properties (which is a specific case, only when editing), it would not require me to expose a different typename, but maybe adding it is better, or maybe I've missed understanding something or this is a quite bad approach.

This sounds like a schema design issue though. I'm not 100% sure I follow what you mean,
but I'd assume you're exposing two different sets of data as the same GraphQL object and ending up with the same key.

I'm not sure what your schema says about this object and why one would have no name but that sounds like an implementation issue.

However, if this is not an implementation issue and intended, then it sounds more like from a data modelling perspective you're not either splitting or differentiating these objects.

Either way, no-cache is not the fix here, because, from a GraphQL perspective it sounds like you have an overlap of data that is as modelled in the schema. In such a case, the normalised cache is behaving as intended.

Yeah, you can think of it as a Product model, which has different names in different countries. If you create a Product clone then this clone doesn't have a name and it inherits it respectively. However, since in the edit page, I want the raw cloned object to compare what is inherited, querying it like that will put incorrect values in the cache.

Anyway, it's not big of a deal for me to differentiate the objects, just curious.