[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17777429#comment-17777429
]
Ruben Q L commented on CALCITE-6061:
------------------------------------
Agree with [~julianhyde] and [~mbudiu]. Even if the specification says that
"the order is not guaranteed", that does not mean that "the order must not be
guaranteed" (as the description of the current ticket seems to imply).
Using a LinkedHashMap is totally valid, and has some advantages (as others have
mentioned before).
> MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
> ---------------------------------------------------------------------
>
> Key: CALCITE-6061
> URL: https://issues.apache.org/jira/browse/CALCITE-6061
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.35.0
> Reporter: Ran Tao
> Priority: Major
>
> when we call:
> {code:java}
> select map[1,2,3,4,5,6];{code}
> The order of results returned is the same every time.
> {code:java}
> +-----------------+
> | EXPR$0 |
> +-----------------+
> | {1=2, 3=4, 5=6} |
> +-----------------+
> {code}
> because calcite use LinkedHashMap for storage. But semantically, the order
> should not be guaranteed just like MULTISET.
> we can see other engines such as apache spark/flink just use HashMap in this
> case.
> {code:java}
> Flink SQL> select map[1,2,3,4,5,6];
> +----+--------------------------------+
> | op | EXPR$0 |
> +----+--------------------------------+
> | +I | {5=6, 1=2, 3=4} |
> +----+--------------------------------+
> Received a total of 1 row {code}
> it will return different order when you call it.
> [https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
