[
https://issues.apache.org/jira/browse/FLINK-25699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481922#comment-17481922
]
Francesco Guardiani commented on FLINK-25699:
---------------------------------------------
{quote}In theory both could be valid \{1=2,3=4} and \{3=4,1=2}
{quote}
In general, I agree with this statement, but I don't think you can go ahead and
fix this easily without dramatically changing the way we handle {{MapData}}.
Our maps are essentially represented as two arrays, and assuming input keys are
already deduped, the rest of the implementation behaves more like a
{{LinkedHashMap}} than a {{Map}}.
So for me, when creating a map, I think it's ok if the constructor scrambles
the order, as it's part of the contract of {{Map}} that you should not rely on
the order.
{quote}I would actually suggest to sort the keys after converting them to
string for the cast-to-string rule. Otherwise the result is always
non-deterministic. However, this is quite expensive. In general, comparing
based on string is always dangerous. We could also always just choose the value
creation order like in your example.
{quote}
I think we should not do that, exactly because we should not encourage users to
rely on the string representation for comparison. Even in Java this is not
deterministic for {{HashMap}}, while it is for {{LinkedHashMap}}:
[https://docs.oracle.com/javase/8/docs/api/java/util/AbstractMap.html#toString--].
> Use HashMap for MAP value constructors
> --------------------------------------
>
> Key: FLINK-25699
> URL: https://issues.apache.org/jira/browse/FLINK-25699
> Project: Flink
> Issue Type: Sub-task
> Components: Table SQL / Runtime
> Reporter: Timo Walther
> Assignee: Sergey Nuyanzin
> Priority: Major
>
> Currently, the usage of maps is inconsistent. It is not ensured that
> duplicate keys get eliminated. For CAST and output conversion this is solved.
> However, we should have a similar implementation in MAP value constructor
> like in CAST.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
