Why does ExecutionResult#getExtensions() returns Map<Object, Object> while addExtension() only accepts a String key?
#3729
-
|
The title kinda says it all, I'm trying to understand the reasoning for it returning a This issue arose when creating a converter to protobuf and trying to feed |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
I think this is bad modelling in retrospect. The graphql spec says nothing about what it should be https://spec.graphql.org/October2021/#sec-Response-Format
It says it should be a map not what type of map. I think we have modelled this too loosely. In retrospection I think a But nominally we are serialisation independent and in theory (but probably not in practice) some serialisation could support non string key maps say. But this is a weak argument in reality |
Beta Was this translation helpful? Give feedback.
-
I had the same interpretation of the spec, couldn't come up with any use case where the map would contain some other arbitrary type as key, as you mentioned (and probably also GraphQL's main serialisation format) it will become a JSON which requires keys to be strings. Even though modelled too loosely I'd put the blame square on the spec by not being more precise, if I at least could find a use case where a key of any other type would be useful for the Thanks a lot for the quick answer, I believe I will be safe when serialising to protobuf to assume the keys to always be strings for my usage :) |
Beta Was this translation helpful? Give feedback.
I think this is bad modelling in retrospect.
The graphql spec says nothing about what it should be
https://spec.graphql.org/October2021/#sec-Response-Format
It says it should be a map not what type of map.
I think we have modelled this too loosely. In retrospection I think a
Map<String,Object>would have been better since it all often becomes JSON anyway and needs keys to be strings in effect.But nominally we are serialisation …