[jira] [Commented] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1519#comment-1519
]
Ran Tao commented on CALCITE-6061:
--
thank you all. I'm ok with this. then i will close this ticket.
> 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)
[jira] [Commented] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1429#comment-1429
]
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)
[jira] [Commented] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1400#comment-1400
]
Julian Hyde commented on CALCITE-6061:
--
{quote}from a runtime perspective, should we return a hashmap?{quote}
I don't think we *return* anything. People can get the data via JDBC. But the
fact that we happen to store the data in a {{LinkedHashMap}} (or other java
class) while computing the result is an implementation detail.
> 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)
[jira] [Commented] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1391#comment-1391
]
Ran Tao commented on CALCITE-6061:
--
IMHO, Because we should follow the definition of MAP itself, LinkedHashMap or
TreeMap, etc. are special implementations.
> 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)
[jira] [Commented] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1379#comment-1379
]
Mihai Budiu commented on CALCITE-6061:
--
Why not just Map?
> 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)
[jira] [Commented] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1369#comment-1369
]
Ran Tao commented on CALCITE-6061:
--
In general, I agree with you, but I don't agree with you very much about the
test. For the test, we can ensure that the order is fixed through other way,
but from a runtime perspective, should we return a hashmap?
> 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. 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)
[jira] [Commented] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1366#comment-1366
]
Julian Hyde commented on CALCITE-6061:
--
I agree with [~mbudiu] that it's not a bug. The specification does not
guarantee order but it's ok if our implementation has deterministic order. (I
know it's a rather subtle point, because there is only one implementation of
the specification.)
In fact, if our implementation is deterministic, it makes it easier for us to
test.
When does the specification matter? One example. If we were to implement an
'equals' operation between two maps, the maps would be equal if they have the
same keys and values, regardless of order.
> 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];{code}
> The order of results returned is the same every time. 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.
> [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)
