Local cache mutations are mutable and the properties have both get and set accessors generated. This is fine for scalar and entity type properties but causes a problem with type conditions.
The problem is that the setter for the type condition is only changing the internal Dictionary (_data) value but none of the metadata (_fulfilledFragments and _deferredFragments) needed during execution. The result is that if a selection set is instantiated and then the type condition setter overwrites the underlying data, committing that data to the cache often results in errors when execution is performed.
Is this a breaking change?
The correct way to initialize a selection set through a type condition is to use the asRootEntityType property which correctly sets the underlying DataDict which in turn handles the internal Dictionary storage and the associated execution metadata. This exists already and is documented.
The existing type case setters are causing unintended runtime errors and were not intended to be used this way therefore I do not think removing them should be considered a breaking change.
Local cache mutations are mutable and the properties have both
get
andset
accessors generated. This is fine for scalar and entity type properties but causes a problem with type conditions.The problem is that the setter for the type condition is only changing the internal Dictionary (
_data
) value but none of the metadata (_fulfilledFragments
and_deferredFragments
) needed during execution. The result is that if a selection set is instantiated and then the type condition setter overwrites the underlying data, committing that data to the cache often results in errors when execution is performed.Is this a breaking change? The correct way to initialize a selection set through a type condition is to use the
asRootEntityType
property which correctly sets the underlyingDataDict
which in turn handles the internalDictionary
storage and the associated execution metadata. This exists already and is documented.The existing type case setters are causing unintended runtime errors and were not intended to be used this way therefore I do not think removing them should be considered a breaking change.