[jira] [Updated] (CALCITE-2881) Add the JSON_PRETTY function
[
https://issues.apache.org/jira/browse/CALCITE-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ritesh updated CALCITE-2881:
Description:
```
JSON_PRETTY(*json_doc*)
```
Returns the pretty formatted JSON document. Returns `NULL` if any argument is
`NULL` or if JSON document is invalid.
Example Sql:
```sql
SELECT JSON_PRETTY(v) AS c1
FROM (VALUES ('{"a": [10, true],"b": [10, true]}')) as t(v)
limit 10
```
Result:
c1
{ "a" : [ 10, true ], "b" : [ 10, true ] }
was:
```
JSON_PRETTY(*json_string_doc*)
```
Returns the pretty formatted JSON document. Returns `NULL` if any argument is
`NULL` or if JSON document is invalid.
Example Sql:
```sql
SELECT JSON_PRETTY(v) AS c1
FROM (VALUES ('\{"a": [10, true],"b": [10, true]}')) as t(v)
limit 10
```
Result:
c1
{ "a" : [ 10, true ], "b" : [ 10, true ] }
> Add the JSON_PRETTY function
>
>
> Key: CALCITE-2881
> URL: https://issues.apache.org/jira/browse/CALCITE-2881
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Ritesh
>Priority: Major
>
> ```
> JSON_PRETTY(*json_doc*)
> ```
> Returns the pretty formatted JSON document. Returns `NULL` if any argument is
> `NULL` or if JSON document is invalid.
> Example Sql:
> ```sql
> SELECT JSON_PRETTY(v) AS c1
> FROM (VALUES ('{"a": [10, true],"b": [10, true]}')) as t(v)
> limit 10
> ```
> Result:
> c1
> { "a" : [ 10, true ], "b" : [ 10, true ] }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2880) Add the JSON_PRETTY function
[
https://issues.apache.org/jira/browse/CALCITE-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ritesh updated CALCITE-2880:
Description:
```
JSON_PRETTY(**json_string_doc**)
```
Returns the pretty formatted JSON document. Returns `NULL` if any argument is
`NULL` or if JSON document is invalid.
Example Sql:
```sql
SELECT JSON_PRETTY(v) AS c1
FROM (VALUES ('\{"a": [10, true],"b": [10, true]}')) as t(v)
limit 10
```
Result:
|c1|
||
|{
"a" : [ 10, true ],
"b" : [ 10, true ]
}|
was:
```
JSON_LENGTH(**json_doc**[, *path*])
```
Returns the length of a JSON document, or, if a *path* argument is given, the
length of the value within the document identified by the path. Returns `NULL`
if any argument is `NULL` or the *path* argument does not identify a value in
the document. An error occurs if the *json_doc* argument is not a valid JSON
document or the *path* argument is not a valid path expression or contains a
\{**} or }}**{{`*` wildcard.
The length of a document is determined as follows:
- The length of a scalar is 1.
- The length of an array is the number of array elements.
- The length of an object is the number of object members.
- The length does not count the length of nested arrays or objects.
Example Sql:
```sql
SELECT JSON_LENGTH(v, 'lax $' ERROR ON ERROR) AS c1
,JSON_LENGTH(v, 'lax $.a' ERROR ON ERROR) AS c2
,JSON_LENGTH(v, 'strict $.a[0]' ERROR ON ERROR) AS c3
,JSON_LENGTH(v, 'strict $.a[1]' ERROR ON ERROR) AS c4
FROM (VALUES ('\{"a": [10, true]}')) AS t(v)
limit 10;
```
Result:
| c1 | c2 | c3 | c4 |
| | | | |
| 1 | 2 | 1 | 1 |
> Add the JSON_PRETTY function
> -
>
> Key: CALCITE-2880
> URL: https://issues.apache.org/jira/browse/CALCITE-2880
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Ritesh
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
>
> ```
> JSON_PRETTY(**json_string_doc**)
> ```
> Returns the pretty formatted JSON document. Returns `NULL` if any argument is
> `NULL` or if JSON document is invalid.
> Example Sql:
> ```sql
> SELECT JSON_PRETTY(v) AS c1
> FROM (VALUES ('\{"a": [10, true],"b": [10, true]}')) as t(v)
> limit 10
> ```
> Result:
> |c1|
> ||
> |{
> "a" : [ 10, true ],
> "b" : [ 10, true ]
> }|
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2881) Add the JSON_PRETTY function
Ritesh created CALCITE-2881:
---
Summary: Add the JSON_PRETTY function
Key: CALCITE-2881
URL: https://issues.apache.org/jira/browse/CALCITE-2881
Project: Calcite
Issue Type: Sub-task
Reporter: Ritesh
```
JSON_PRETTY(*json_string_doc*)
```
Returns the pretty formatted JSON document. Returns `NULL` if any argument is
`NULL` or if JSON document is invalid.
Example Sql:
```sql
SELECT JSON_PRETTY(v) AS c1
FROM (VALUES ('\{"a": [10, true],"b": [10, true]}')) as t(v)
limit 10
```
Result:
c1
{ "a" : [ 10, true ], "b" : [ 10, true ] }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CALCITE-2880) Add the JSON_PRETTY function
[
https://issues.apache.org/jira/browse/CALCITE-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ritesh closed CALCITE-2880.
---
Resolution: Invalid
> Add the JSON_PRETTY function
> -
>
> Key: CALCITE-2880
> URL: https://issues.apache.org/jira/browse/CALCITE-2880
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Ritesh
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
>
> ```
> JSON_PRETTY(**json_string_doc**)
> ```
> Returns the pretty formatted JSON document. Returns `NULL` if any argument is
> `NULL` or if JSON document is invalid.
> Example Sql:
> ```sql
> SELECT JSON_PRETTY(v) AS c1
> FROM (VALUES ('\{"a": [10, true],"b": [10, true]}')) as t(v)
> limit 10
> ```
> Result:
> |c1|
> ||
> |{
> "a" : [ 10, true ],
> "b" : [ 10, true ]
> }|
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2880) Add the JSON_PRETTY function
Ritesh created CALCITE-2880:
---
Summary: Add the JSON_PRETTY function
Key: CALCITE-2880
URL: https://issues.apache.org/jira/browse/CALCITE-2880
Project: Calcite
Issue Type: Sub-task
Reporter: Ritesh
Assignee: Forward Xu
```
JSON_LENGTH(**json_doc**[, *path*])
```
Returns the length of a JSON document, or, if a *path* argument is given, the
length of the value within the document identified by the path. Returns `NULL`
if any argument is `NULL` or the *path* argument does not identify a value in
the document. An error occurs if the *json_doc* argument is not a valid JSON
document or the *path* argument is not a valid path expression or contains a
\{**} or }}**{{`*` wildcard.
The length of a document is determined as follows:
- The length of a scalar is 1.
- The length of an array is the number of array elements.
- The length of an object is the number of object members.
- The length does not count the length of nested arrays or objects.
Example Sql:
```sql
SELECT JSON_LENGTH(v, 'lax $' ERROR ON ERROR) AS c1
,JSON_LENGTH(v, 'lax $.a' ERROR ON ERROR) AS c2
,JSON_LENGTH(v, 'strict $.a[0]' ERROR ON ERROR) AS c3
,JSON_LENGTH(v, 'strict $.a[1]' ERROR ON ERROR) AS c4
FROM (VALUES ('\{"a": [10, true]}')) AS t(v)
limit 10;
```
Result:
| c1 | c2 | c3 | c4 |
| | | | |
| 1 | 2 | 1 | 1 |
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2877) GeodeSchema change to make the constructor public to pass the client cahe directly
[
https://issues.apache.org/jira/browse/CALCITE-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780089#comment-16780089
]
Andrei Sereda commented on CALCITE-2877:
[~julianhyde] this is in response to our discussion on [dev
list|https://lists.apache.org/thread.html/8c255842f5c8885d772c27546d5fe12dd4e2f2d124ac6ad221e47519@%3Cdev.calcite.apache.org%3E].
If using JNDI one has to make client code depend on JNDI plus we have to remove
connection from directory service when it is closed (to avoid memory leaks).
It seems to create more problems than solving.
{quote}
There’s nothing stopping you from creating schemas (or trees of schemas)
manually. And yes, you can put whatever kinds of objects you like as
constructor parameters for your schema. But if you want to use SchemaFactory,
or model JSON, or you want your plan to be instantiable in a different context
or VM, you have to play by the rules.
{quote}
> GeodeSchema change to make the constructor public to pass the client cahe
> directly
> --
>
> Key: CALCITE-2877
> URL: https://issues.apache.org/jira/browse/CALCITE-2877
> Project: Calcite
> Issue Type: Improvement
> Components: geode
>Reporter: Sandeep Chada
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> GeodeSchema change to make the constructor public to pass the client cahe
> directly
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2864) Add the JSON_DEPTH function
[
https://issues.apache.org/jira/browse/CALCITE-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780081#comment-16780081
]
Forward Xu commented on CALCITE-2864:
-
hi [~zhztheplayer] oh，sorry， The file is not to be use.
> Add the JSON_DEPTH function
> ---
>
> Key: CALCITE-2864
> URL: https://issues.apache.org/jira/browse/CALCITE-2864
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.19.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Returns the maximum depth of a JSON document. Returns {{NULL}} if the
> argument is {{NULL}}. An error occurs if the argument is not a valid JSON
> document.
> An empty array, empty object, or scalar value has depth 1. A nonempty array
> containing only elements of depth 1 or nonempty object containing only member
> values of depth 1 has depth 2. Otherwise, a JSON document has depth greater
> than 2.
>
> Example Sql:
> SELECT JSON_DEPTH(v) AS c1
> ,JSON_DEPTH(JSON_VALUE(v, 'lax $.b' ERROR ON ERROR)) AS c2
> ,JSON_DEPTH(JSON_VALUE(v, 'strict $.a[0]' ERROR ON ERROR)) AS c3
> ,JSON_DEPTH(JSON_VALUE(v, 'strict $.a[1]' ERROR ON ERROR)) AS c4
> FROM (VALUES ('
> {"a": [10, true],"b": "[10, true]"}
> ')) AS t(v)
> limit 10;
> Result:
> c1 c2 c3 c4
> == == == ==
> 3 2 1 1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2457) Upgrade to JUnit 5
[ https://issues.apache.org/jira/browse/CALCITE-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-2457: Labels: pull-request-available (was: ) > Upgrade to JUnit 5 > -- > > Key: CALCITE-2457 > URL: https://issues.apache.org/jira/browse/CALCITE-2457 > Project: Calcite > Issue Type: Improvement >Reporter: Vladimir Sitnikov >Priority: Major > Labels: pull-request-available > Attachments: assert_equals.png, truth_assertmap.png > > > JUnit 5 brings multiple useful features so tests are easier to read and write. > Is there something that blocks upgrading to JUnit 5? > By upgrade I mean bumping up the dependency version and creating new tests > with JUnit 5 features. > Relevant features of JUnit 5: dynamic test, nested tests, parameterized tests > https://twitter.com/nipafx/status/1027095088059559936 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2864) Add the JSON_DEPTH function
[
https://issues.apache.org/jira/browse/CALCITE-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780075#comment-16780075
]
Hongze Zhang commented on CALCITE-2864:
---
[~x1q1j1], [~michaelmior], sorry for re-pinging you. The fix seems to introduce
a tiny unused test-generated file
[https://github.com/apache/calcite/blob/master/core/custom-schema-model.json],
It is not a big deal and I am going to remove it with a follow-up commit,
please let me know if the file is still useful.
> Add the JSON_DEPTH function
> ---
>
> Key: CALCITE-2864
> URL: https://issues.apache.org/jira/browse/CALCITE-2864
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.19.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Returns the maximum depth of a JSON document. Returns {{NULL}} if the
> argument is {{NULL}}. An error occurs if the argument is not a valid JSON
> document.
> An empty array, empty object, or scalar value has depth 1. A nonempty array
> containing only elements of depth 1 or nonempty object containing only member
> values of depth 1 has depth 2. Otherwise, a JSON document has depth greater
> than 2.
>
> Example Sql:
> SELECT JSON_DEPTH(v) AS c1
> ,JSON_DEPTH(JSON_VALUE(v, 'lax $.b' ERROR ON ERROR)) AS c2
> ,JSON_DEPTH(JSON_VALUE(v, 'strict $.a[0]' ERROR ON ERROR)) AS c3
> ,JSON_DEPTH(JSON_VALUE(v, 'strict $.a[1]' ERROR ON ERROR)) AS c4
> FROM (VALUES ('
> {"a": [10, true],"b": "[10, true]"}
> ')) AS t(v)
> limit 10;
> Result:
> c1 c2 c3 c4
> == == == ==
> 3 2 1 1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CALCITE-2864) Add the JSON_DEPTH function
[
https://issues.apache.org/jira/browse/CALCITE-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Forward Xu closed CALCITE-2864.
---
> Add the JSON_DEPTH function
> ---
>
> Key: CALCITE-2864
> URL: https://issues.apache.org/jira/browse/CALCITE-2864
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.19.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Returns the maximum depth of a JSON document. Returns {{NULL}} if the
> argument is {{NULL}}. An error occurs if the argument is not a valid JSON
> document.
> An empty array, empty object, or scalar value has depth 1. A nonempty array
> containing only elements of depth 1 or nonempty object containing only member
> values of depth 1 has depth 2. Otherwise, a JSON document has depth greater
> than 2.
>
> Example Sql:
> SELECT JSON_DEPTH(v) AS c1
> ,JSON_DEPTH(JSON_VALUE(v, 'lax $.b' ERROR ON ERROR)) AS c2
> ,JSON_DEPTH(JSON_VALUE(v, 'strict $.a[0]' ERROR ON ERROR)) AS c3
> ,JSON_DEPTH(JSON_VALUE(v, 'strict $.a[1]' ERROR ON ERROR)) AS c4
> FROM (VALUES ('
> {"a": [10, true],"b": "[10, true]"}
> ')) AS t(v)
> limit 10;
> Result:
> c1 c2 c3 c4
> == == == ==
> 3 2 1 1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2827) Allow CONVENTION.NONE planning with VolcanoPlanner
[ https://issues.apache.org/jira/browse/CALCITE-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779974#comment-16779974 ] Laurent Goujon commented on CALCITE-2827: - Didn't I answer it? Our planner has a planning phase when there's no convention change, but we are looking for a cost-based solution when applying different rules. Because NONE convention has always infinite cost, by default VolcanoPlanner cannot answer it. Note that if nodes were using a different convention, it would not be issue. I interpret this as VolcanoPlanner has an optimization to not compute cost for nodes with NONE convention since in most cases we are interested in finding the best solution in a different convention. But maybe that optimization could be generalized, and the optimization would be to not compute cost for the source convention, and make the optimization optional. If you think I merged the change too soon (but from [~michaelmior] PR comment, I didn't think it was too much controversial), I don't mind reverting. > Allow CONVENTION.NONE planning with VolcanoPlanner > -- > > Key: CALCITE-2827 > URL: https://issues.apache.org/jira/browse/CALCITE-2827 > Project: Calcite > Issue Type: Task >Reporter: Siddharth Teotia >Assignee: Juhwan Kim >Priority: Minor > Labels: pull-request-available > Fix For: 1.19.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2864) Add the JSON_DEPTH function
[
https://issues.apache.org/jira/browse/CALCITE-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779941#comment-16779941
]
Hongze Zhang edited comment on CALCITE-2864 at 2/28/19 12:27 AM:
-
It seems that for now the {{JSON_DEPTH}} (also {{JSON_TYPE}}) expects a
{{JsonValueExpression}}[1] as input. It's a common pattern to construct a JSON
value. E.g. using {{JSON_DEPTH(col FORMAT AVRO)}} to handle avro JSON data (but
we now don't support avro format).
I think we can integrate {{JsonValueExpression}} into {{Expression}}[2] in
future(maybe in the fix of CALCITE-2869[3], although we did't start to discuss
that issue), then remove the parser changes of {{JSON_DEPTH}} and {{JSON_TYPE}}
and so on.
[1]
[https://github.com/apache/calcite/blob/5101703c3bb7e051766f9dc932534a0a7acba0c5/core/src/main/codegen/templates/Parser.jj#L4892]
[2]
[https://github.com/apache/calcite/blob/e3a319e1f79bc807327bd443433c50c4bbf20866/core/src/main/codegen/templates/Parser.jj#L2991]
[3] https://issues.apache.org/jira/browse/CALCITE-2869
was (Author: zhztheplayer):
It seems that for now the {{JSON_DEPTH}} (also {{JSON_TYPE}}) expects a
{{JsonValueExpression}}[1] as input. It's a common pattern to construct a JSON
value. E.g. using {{JSON_DEPTH(col FORMAT AVRO)}} to handle avro JSON data (but
we now don't support avro format).
I think we can integrate {{JsonValueExpression}} into {{Expression}}[2] in
future(maybe in the fix of 2869, although we did't start to discuss that
issue), then remove the parser changes of {{JSON_DEPTH}} and {{JSON_TYPE}} and
so on.
[1]
[https://github.com/apache/calcite/blob/5101703c3bb7e051766f9dc932534a0a7acba0c5/core/src/main/codegen/templates/Parser.jj#L4892]
[2]
[https://github.com/apache/calcite/blob/e3a319e1f79bc807327bd443433c50c4bbf20866/core/src/main/codegen/templates/Parser.jj#L2991]
> Add the JSON_DEPTH function
> ---
>
> Key: CALCITE-2864
> URL: https://issues.apache.org/jira/browse/CALCITE-2864
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.19.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Returns the maximum depth of a JSON document. Returns {{NULL}} if the
> argument is {{NULL}}. An error occurs if the argument is not a valid JSON
> document.
> An empty array, empty object, or scalar value has depth 1. A nonempty array
> containing only elements of depth 1 or nonempty object containing only member
> values of depth 1 has depth 2. Otherwise, a JSON document has depth greater
> than 2.
>
> Example Sql:
> SELECT JSON_DEPTH(v) AS c1
> ,JSON_DEPTH(JSON_VALUE(v, 'lax $.b' ERROR ON ERROR)) AS c2
> ,JSON_DEPTH(JSON_VALUE(v, 'strict $.a[0]' ERROR ON ERROR)) AS c3
> ,JSON_DEPTH(JSON_VALUE(v, 'strict $.a[1]' ERROR ON ERROR)) AS c4
> FROM (VALUES ('
> {"a": [10, true],"b": "[10, true]"}
> ')) AS t(v)
> limit 10;
> Result:
> c1 c2 c3 c4
> == == == ==
> 3 2 1 1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2864) Add the JSON_DEPTH function
[
https://issues.apache.org/jira/browse/CALCITE-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779941#comment-16779941
]
Hongze Zhang commented on CALCITE-2864:
---
It seems that for now the {{JSON_DEPTH}} (also {{JSON_TYPE}}) expects a
{{JsonValueExpression}}[1] as input. It's a common pattern to construct a JSON
value. E.g. using {{JSON_DEPTH(col FORMAT AVRO)}} to handle avro JSON data (but
we now don't support avro format).
I think we can integrate {{JsonValueExpression}} into {{Expression}}[2] in
future(maybe in the fix of 2869, although we did't start to discuss that
issue), then remove the parser changes of {{JSON_DEPTH}} and {{JSON_TYPE}} and
so on.
[1]
[https://github.com/apache/calcite/blob/5101703c3bb7e051766f9dc932534a0a7acba0c5/core/src/main/codegen/templates/Parser.jj#L4892]
[2]
[https://github.com/apache/calcite/blob/e3a319e1f79bc807327bd443433c50c4bbf20866/core/src/main/codegen/templates/Parser.jj#L2991]
> Add the JSON_DEPTH function
> ---
>
> Key: CALCITE-2864
> URL: https://issues.apache.org/jira/browse/CALCITE-2864
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.19.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Returns the maximum depth of a JSON document. Returns {{NULL}} if the
> argument is {{NULL}}. An error occurs if the argument is not a valid JSON
> document.
> An empty array, empty object, or scalar value has depth 1. A nonempty array
> containing only elements of depth 1 or nonempty object containing only member
> values of depth 1 has depth 2. Otherwise, a JSON document has depth greater
> than 2.
>
> Example Sql:
> SELECT JSON_DEPTH(v) AS c1
> ,JSON_DEPTH(JSON_VALUE(v, 'lax $.b' ERROR ON ERROR)) AS c2
> ,JSON_DEPTH(JSON_VALUE(v, 'strict $.a[0]' ERROR ON ERROR)) AS c3
> ,JSON_DEPTH(JSON_VALUE(v, 'strict $.a[1]' ERROR ON ERROR)) AS c4
> FROM (VALUES ('
> {"a": [10, true],"b": "[10, true]"}
> ')) AS t(v)
> limit 10;
> Result:
> c1 c2 c3 c4
> == == == ==
> 3 2 1 1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2397) Column Index not getting set on correlationIds
[ https://issues.apache.org/jira/browse/CALCITE-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-2397: - Labels: pull-request-available (was: ) > Column Index not getting set on correlationIds > -- > > Key: CALCITE-2397 > URL: https://issues.apache.org/jira/browse/CALCITE-2397 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.16.0 >Reporter: James Duong >Priority: Major > Labels: pull-request-available > > During SqlToRel conversion, the column index bitset is not getting set on > CorrelationIds. This causes getCorrelationId() to always return empty. > Also get/setColumnIndex() have been removed from CorrelationId -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2496) EXTRACT function: MILLI/MICRO/NANOSECOND parts of a DATE must be zero
[
https://issues.apache.org/jira/browse/CALCITE-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-2496:
-
Labels: pull-request-available (was: )
> EXTRACT function: MILLI/MICRO/NANOSECOND parts of a DATE must be zero
> -
>
> Key: CALCITE-2496
> URL: https://issues.apache.org/jira/browse/CALCITE-2496
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Sergey Nuyanzin
>Priority: Major
> Labels: pull-request-available
>
> There was already a similar issue CALCITE-2324 but I'm sorry I did not take
> into account 3 time units. Now I want to cover them here. So all existing
> Timeunits from {{org.apache.calcite.avatica.util.TimeUnit}} which are less
> than a day will be covered
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2348) Handling non-deterministic operator in rules
[
https://issues.apache.org/jira/browse/CALCITE-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-2348:
-
Summary: Handling non-deterministic operator in rules (was: handling
non-deterministic operator in rules)
> Handling non-deterministic operator in rules
>
>
> Key: CALCITE-2348
> URL: https://issues.apache.org/jira/browse/CALCITE-2348
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: godfrey he
>Priority: Major
> Labels: pull-request-available
>
> Currently, rules do not handle non-deterministic operator,
> e.g. FilterAggregateTransposeRule can't push down a non-deterministic filter
> through an aggregate.
> {code:java}
> // rand_substr is a non-deterministic udf
> @Test public void testPushFilterPastAggWithNondeterministicFilter() {
> final String sql = "select ename, empno, c from\n"
> + " (select ename, empno, count(*) as c from emp group by ename, empno)
> t\n"
> + " where rand_substr(ename, 1, 3) = 'Tom' and empno = 10";
> checkPlanning(FilterAggregateTransposeRule.INSTANCE, sql);
> }{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2589) VolcanoPlanner#fireRules and VolcanoRuleCall#matchRecurse should ignore known-to-be-unimportant relations
[
https://issues.apache.org/jira/browse/CALCITE-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-2589:
-
Labels: pull-request-available (was: )
> VolcanoPlanner#fireRules and VolcanoRuleCall#matchRecurse should ignore
> known-to-be-unimportant relations
> -
>
> Key: CALCITE-2589
> URL: https://issues.apache.org/jira/browse/CALCITE-2589
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: Vladimir Sitnikov
>Priority: Major
> Labels: pull-request-available
>
> {{call.getPlanner().setImportance}} is used to avoid use of
> known-to-be-inefficient relation, however the check of importance is
> performed very late.
> The check is performed in org.apache.calcite.plan.volcano.RuleQueue#skipMatch
> when ruleCalls have already been created.
> I suggest to move the check into VolcanoPlanner#fireRules and
> VolcanoRuleCall#matchRecurse
> It would reduce amount of "possible" rule executions.
> Note: calling setImportance BEFORE transformTo would would help as well to
> filter out unimportant rule calls early.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2223) ProjectMergeRule is infinitely matched when is applied after ProjectReduceExpressionsRule
[
https://issues.apache.org/jira/browse/CALCITE-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-2223:
-
Labels: pull-request-available (was: )
> ProjectMergeRule is infinitely matched when is applied after
> ProjectReduceExpressionsRule
> -
>
> Key: CALCITE-2223
> URL: https://issues.apache.org/jira/browse/CALCITE-2223
> Project: Calcite
> Issue Type: Bug
>Reporter: Volodymyr Vysotskyi
>Priority: Critical
> Labels: pull-request-available
> Attachments:
> TestLimitWithExchanges_testPushLimitPastUnionExchange.png, heap_overview.png,
> provenance_contents.png
>
>
> For queries like this:
> {code:sql}
> select t1.f from (select cast(f as int) f, f from (select cast(f as int) f
> from (values('1')) t(f))) as t1
> {code}
> OOM is thrown when {{ProjectMergeRule}} is applied before applying
> {{ProjectReduceExpressionsRule}} in VolcanoPlanner.
> A simple test to reproduce this issue (in {{RelOptRulesTest}}):
> {code:java}
> @Test public void testOomProjectMergeRule() {
> RelBuilder relBuilder =
> RelBuilder.create(RelBuilderTest.config().build());
> RelNode relNode = relBuilder
> .values(new String[]{"f"}, "1")
> .project(
> relBuilder.alias(
> relBuilder.cast(relBuilder.field(0), SqlTypeName.INTEGER),
> "f"))
> .project(
> relBuilder.alias(
> relBuilder.cast(relBuilder.field(0), SqlTypeName.INTEGER),
> "f0"),
> relBuilder.alias(relBuilder.field(0), "f"))
> .project(
> relBuilder.alias(relBuilder.field(0), "f"))
> .build();
> RelOptPlanner planner = relNode.getCluster().getPlanner();
> RuleSet ruleSet =
> RuleSets.ofList(
> ReduceExpressionsRule.PROJECT_INSTANCE,
> new ProjectMergeRuleWithLongerName(),
> EnumerableRules.ENUMERABLE_PROJECT_RULE,
> EnumerableRules.ENUMERABLE_VALUES_RULE);
> Program program = Programs.of(ruleSet);
> RelTraitSet toTraits =
> relNode.getCluster().traitSet()
> .replace(0, EnumerableConvention.INSTANCE);
> RelNode output = program.run(planner, relNode, toTraits,
> ImmutableList.of(),
> ImmutableList.of());
> // check for output
> }
> /**
>* ProjectMergeRule inheritor which has
>* class name greater than ProjectReduceExpressionsRule class name
> (String.compareTo()).
>*
>* It is needed for RuleQueue.popMatch() method
>* to apply this rule before ProjectReduceExpressionsRule.
>*/
> private static class ProjectMergeRuleWithLongerName extends
> ProjectMergeRule {
> public ProjectMergeRuleWithLongerName() {
> super(true, RelFactories.LOGICAL_BUILDER);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2460) Add implementation of To_Base64 to SqlFunctions
[ https://issues.apache.org/jira/browse/CALCITE-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-2460: - Labels: pull-request-available (was: ) > Add implementation of To_Base64 to SqlFunctions > --- > > Key: CALCITE-2460 > URL: https://issues.apache.org/jira/browse/CALCITE-2460 > Project: Calcite > Issue Type: Improvement >Reporter: vinoyang >Priority: Minor > Labels: pull-request-available > > refer to mysql TO_BASE64 function : > [https://dev.mysql.com/doc/refman/5.6/en/string-functions.html#function_to-base64] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-1776) Implement CORR and REGR_* aggregate functions
[ https://issues.apache.org/jira/browse/CALCITE-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-1776: - Labels: pull-request-available (was: ) > Implement CORR and REGR_* aggregate functions > - > > Key: CALCITE-1776 > URL: https://issues.apache.org/jira/browse/CALCITE-1776 > Project: Calcite > Issue Type: New Feature >Reporter: Dmitri Shtilman >Priority: Minor > Labels: pull-request-available > > Implement correlation coefficient aggregate: CORR > As well as the missing regression aggregates: > REGR_SLOPE, REGR_INTERCEPT, REGR_COUNT, REGR_R2, REGR_AVGX, REGR_AVGY, > REGR_SXY > For reference, REGR_SXX and REGR_SYY have been added in [CALCITE-422] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2414) CUME_DIST/PERCENT_RUNK window functions
[ https://issues.apache.org/jira/browse/CALCITE-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-2414: - Labels: pull-request-available (was: ) > CUME_DIST/PERCENT_RUNK window functions > --- > > Key: CALCITE-2414 > URL: https://issues.apache.org/jira/browse/CALCITE-2414 > Project: Calcite > Issue Type: New Feature >Reporter: Sergey Nuyanzin >Priority: Major > Labels: pull-request-available > > iCUME_DIST/PERCENT_RUNK are mentioned in Not Implemented section in > http://calcite.apache.org/docs/reference.html > At the same time they come with SQL:2003 > Here there is a suggestion to implement it -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2453) Enhance the SQL parser in order to optionally support semicolon at the end of the sql statements
[ https://issues.apache.org/jira/browse/CALCITE-2453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-2453: - Labels: pull-request-available (was: ) > Enhance the SQL parser in order to optionally support semicolon at the end of > the sql statements > > > Key: CALCITE-2453 > URL: https://issues.apache.org/jira/browse/CALCITE-2453 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: next >Reporter: charbel yazbeck >Priority: Trivial > Labels: pull-request-available > Attachments: > 0001-CALCITE-2453-Allowing-SQL-statements-to-optionally-e.patch > > > Consists of adding [] in Parser.jj -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2456) VolcanoRuleCall#match works incorrectly for unordered child operand
[ https://issues.apache.org/jira/browse/CALCITE-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-2456: - Labels: pull-request-available (was: ) > VolcanoRuleCall#match works incorrectly for unordered child operand > --- > > Key: CALCITE-2456 > URL: https://issues.apache.org/jira/browse/CALCITE-2456 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 > Environment: Test on Calcite master branch as of 8/7/2018 with Java 8. >Reporter: Zuozhi Wang >Priority: Major > Labels: pull-request-available > Attachments: UnorderedBugTest.java > > > h2. Bug Description: > This bug occurs when there'a rule matching a Union operator with an unordered > operand: > `operand(Union.class, unordered(operand(RelTypeB.class, any(`, > with an plan tree that the operand to match is not the first input to the > union: > LogicalUnion > RelTypeA > RelTypeB > The expected behavior is that this plan tree should fire the match, because > `unordered` means matching any child of the union operator. > The bug is that the tree is *not* matched as expected, either matching in > descending order (rule is triggered from LogicalUnion) or in ascending order > (rule is triggered by adding another node equivalent to RelTypeB). > h2. How to reproduce: > See the test cases in https://github.com/apache/calcite/pull/784 > h2. Bug cause: > The cause of this issue is that VolcanoRuleCall doesn't handle `unordered` > child operand at all. It uses `operand.ordinalInParent` to check if the > matched RelNode matches the operand's ordinal(position) in parent's inputs. > The value of `ordinalInParent` is always `0` in this case, requires the > matched RelNode to also be the first input. > However, that only makes sense when child policy is `some`, which strictly > requires to match in order. For child policy `unordered`, it should match > regardless of the position of RelNode in the inputs. > h2. Bug fix: > This bug can be fixed with changes to function`VolcanoRuleCall#matchRecurse`: > See [https://github.com/apache/calcite/pull/784] > > Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2442) Cassandra unit test intermittent failures
[
https://issues.apache.org/jira/browse/CALCITE-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-2442:
-
Labels: pull-request-available (was: )
> Cassandra unit test intermittent failures
> -
>
> Key: CALCITE-2442
> URL: https://issues.apache.org/jira/browse/CALCITE-2442
> Project: Calcite
> Issue Type: Bug
> Components: cassandra
>Reporter: Andrei Sereda
>Priority: Major
> Labels: pull-request-available
>
> We have noticed that there are failures due to :
> # Wrong parsing of new [JDK version scheme|http://openjdk.java.net/jeps/223]
> (by calcite and cassandra dependencies like jamm). {{10-ea}} vs {{10.0.2}}
> # Cassandra startup timeout on Linux Jenkins CI server. Contrary to github
> travis CI (the one which validates PRs), it takes about 20s for embedded
> cassandra to start (still under investigation).
> # [~Sergey Nuyanzin] reported that
> [CassandraUnit|https://github.com/jsevellec/cassandra-unit] leaves
> {{.toDelete}} folder in maven module folder ({{cassandra/}}) rather than
> {{target/}} where all build and temporary files should be located. Not a
> failure but annoyance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2421) RexSimplify#simplifyAnds foregoes some simplications if unknownAsFalse set to true
[
https://issues.apache.org/jira/browse/CALCITE-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-2421:
-
Labels: pull-request-available (was: )
> RexSimplify#simplifyAnds foregoes some simplications if unknownAsFalse set to
> true
> --
>
> Key: CALCITE-2421
> URL: https://issues.apache.org/jira/browse/CALCITE-2421
> Project: Calcite
> Issue Type: Bug
>Reporter: Laurent Goujon
>Assignee: Laurent Goujon
>Priority: Minor
> Labels: pull-request-available
>
> It looks like {{RexSimplify#simplifyAnds}} foregoes some comparison
> simplifications if {{unknownAsFalse}} is set to true, like {{A = A AND B =
> B}} which might be simplified to {{A IS NOT NULL AND B IS NOT NULL}} or even
> {{true}} if {{A}} and {{B}} are known to be not nullable.
> One consequence of this is that the selectivity value might be off as a {{=}}
> comparison has a selectivity of 15% whereas {{IS NOT NULL}} has a selectivity
> of 90%.
> The simplication is skipped because {{RexSimplify#simplifyList}} simplify all
> terms with {{unknownAsFalse}} set to {{false}}, but in
> {{RexSimplify#simplifyAnd2ForUnknownAsFalse}}, there's no attempt at trying
> again to simplify each term.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CALCITE-2288) Type assertion error when reducing partially constant expression
[
https://issues.apache.org/jira/browse/CALCITE-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis closed CALCITE-2288.
Resolution: Not A Problem
Fix Version/s: 1.19.0
The problem seems to be solved, so I am closing this issue.
> Type assertion error when reducing partially constant expression
>
>
> Key: CALCITE-2288
> URL: https://issues.apache.org/jira/browse/CALCITE-2288
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Laurent Goujon
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.19.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Probably a follow up of CALCITE-2041
> The following query failed at planning time with an assertion error:
> {code:sql}
> SELECT
> EXTRACT(SECOND FROM CAST(CASE WHEN TRUE THEN {ts '2018-01-01 01:23:45'}
> ELSE NULL END AS TIMESTAMP)) =
> EXTRACT(SECOND FROM d)
> FROM (VALUES({ts '2018-01-01 01:23:45'})) tbl(d
> {code}
> Stacktrace is:
> {noformat}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(BOOLEAN EXPR$0) NOT NULL
> expression type is RecordType(BOOLEAN NOT NULL EXPR$0) NOT NULL
> set is
> rel#4:LogicalProject(input=HepRelVertex#3,EXPR$0==(EXTRACT(FLAG(SECOND),
> CAST(CASE(true, 2018-01-01 01:23:45, null)):TIMESTAMP(0)),
> EXTRACT(FLAG(SECOND), $0)))
> expression is LogicalProject#6
> at
> org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:413)
> at
> org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule$ProjectReduceExpressionsRule.onMatch(ReduceExpressionsRule.java:290)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:317)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:556)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:415)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:252)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:127)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:211)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:198)
> ...
> {noformat}
> As far as I can tell, the issue is in
> {{ReduceExpressionRules#reduceExpressions}}: when the expression is partially
> reduced, the reduced expression lost its type nullability, which is not added
> back by the simplifier.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2395) Support SELECT xxx FROM TABLE FOR UPDATE syntax
[ https://issues.apache.org/jira/browse/CALCITE-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-2395: - Labels: pull-request-available (was: ) > Support SELECT xxx FROM TABLE FOR UPDATE syntax > --- > > Key: CALCITE-2395 > URL: https://issues.apache.org/jira/browse/CALCITE-2395 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.16.0 >Reporter: Enrico Olivelli >Priority: Major > Labels: pull-request-available > > I am using Calcite SQL Parser and Volcano Planner. > I need to support SQL syntax > SELECT ... FROM table FOR UPDATE > > see for instance PostGre docs > [https://www.postgresql.org/docs/9.5/static/sql-select.html.] > > I would like at least to support this syntax at SQL Parser level, the 'for > update' spec should be reported by the RelNode so that the system can take it > into account and perform explicit locking. > > Linked downstream project issue: > https://github.com/diennea/herddb/issues/228 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2399) Allow SqlImplementor classes to be extended
[ https://issues.apache.org/jira/browse/CALCITE-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-2399: - Labels: pull-request-available (was: ) > Allow SqlImplementor classes to be extended > --- > > Key: CALCITE-2399 > URL: https://issues.apache.org/jira/browse/CALCITE-2399 > Project: Calcite > Issue Type: Bug > Components: core, jdbc-adapter >Affects Versions: 1.16.0 >Reporter: James Duong >Priority: Major > Labels: pull-request-available > > Allow SqlImplementor inner classes such as Result to be extended. Add and use > factory methods to instantiate customized instances of these. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-194) Array items in MongoDB adapter
[ https://issues.apache.org/jira/browse/CALCITE-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-194: Labels: github-import pull-request-available (was: github-import) > Array items in MongoDB adapter > -- > > Key: CALCITE-194 > URL: https://issues.apache.org/jira/browse/CALCITE-194 > Project: Calcite > Issue Type: Bug >Reporter: GitHub Import >Assignee: Igor Kryvenko >Priority: Major > Labels: github-import, pull-request-available > > When MongoDB issue href="https://jira.mongodb.org/browse/SERVER-4589;>SERVER-4589, > "aggregation: need an array indexing operator" is fixed, we will be able to > implement > ```sql > SELECT loc[0] AS longitude, loc[1] AS latitude FROM zips > ``` > in the MongoDB adapter. Meantime, look for `Bug.OPTIQnnn_FIXED` in the code. > Imported from GitHub > Url: https://github.com/julianhyde/optiq/issues/194 > Created by: [julianhyde|https://github.com/julianhyde] > Labels: bug, > Created at: Wed Mar 19 00:03:01 CET 2014 > State: open -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2348) handling non-deterministic operator in rules
[
https://issues.apache.org/jira/browse/CALCITE-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-2348:
-
Labels: pull-request-available (was: )
> handling non-deterministic operator in rules
>
>
> Key: CALCITE-2348
> URL: https://issues.apache.org/jira/browse/CALCITE-2348
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: godfrey he
>Priority: Major
> Labels: pull-request-available
>
> Currently, rules do not handle non-deterministic operator,
> e.g. FilterAggregateTransposeRule can't push down a non-deterministic filter
> through an aggregate.
> {code:java}
> // rand_substr is a non-deterministic udf
> @Test public void testPushFilterPastAggWithNondeterministicFilter() {
> final String sql = "select ename, empno, c from\n"
> + " (select ename, empno, count(*) as c from emp group by ename, empno)
> t\n"
> + " where rand_substr(ename, 1, 3) = 'Tom' and empno = 10";
> checkPlanning(FilterAggregateTransposeRule.INSTANCE, sql);
> }{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2343) PushProjector with OVER expression causing infinite loop
[
https://issues.apache.org/jira/browse/CALCITE-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-2343:
-
Labels: pull-request-available (was: )
> PushProjector with OVER expression causing infinite loop
>
>
> Key: CALCITE-2343
> URL: https://issues.apache.org/jira/browse/CALCITE-2343
> Project: Calcite
> Issue Type: Bug
>Reporter: Laurent Goujon
>Assignee: Laurent Goujon
>Priority: Major
> Labels: pull-request-available
>
> When applying the {{ProjectJoinTransposeRule}} on a project with a Rex
> expression containing a RexOver call (using HepPlanner), this might cause an
> infinite loop (and ultimately a StackOverflowError exception) as
> PushProjector identify the RexOver call as to be push down under the join,
> but doesn't not rewrite correctly the top Project expression.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2340) Invalid cast generated by AvgVarianceConvertlet
[
https://issues.apache.org/jira/browse/CALCITE-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-2340:
-
Labels: pull-request-available (was: )
> Invalid cast generated by AvgVarianceConvertlet
> ---
>
> Key: CALCITE-2340
> URL: https://issues.apache.org/jira/browse/CALCITE-2340
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Laurent Goujon
>Assignee: Laurent Goujon
>Priority: Major
> Labels: pull-request-available
>
> A bug in {{AvgVarianceConvertlet}} causes {{CAST}} calls to be generated with
> the wrong number of arguments if the return type of the aggregation function
> is different from the operand.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2288) Type assertion error when reducing partially constant expression
[
https://issues.apache.org/jira/browse/CALCITE-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-2288:
-
Labels: pull-request-available (was: )
> Type assertion error when reducing partially constant expression
>
>
> Key: CALCITE-2288
> URL: https://issues.apache.org/jira/browse/CALCITE-2288
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Laurent Goujon
>Priority: Major
> Labels: pull-request-available
>
> Probably a follow up of CALCITE-2041
> The following query failed at planning time with an assertion error:
> {code:sql}
> SELECT
> EXTRACT(SECOND FROM CAST(CASE WHEN TRUE THEN {ts '2018-01-01 01:23:45'}
> ELSE NULL END AS TIMESTAMP)) =
> EXTRACT(SECOND FROM d)
> FROM (VALUES({ts '2018-01-01 01:23:45'})) tbl(d
> {code}
> Stacktrace is:
> {noformat}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(BOOLEAN EXPR$0) NOT NULL
> expression type is RecordType(BOOLEAN NOT NULL EXPR$0) NOT NULL
> set is
> rel#4:LogicalProject(input=HepRelVertex#3,EXPR$0==(EXTRACT(FLAG(SECOND),
> CAST(CASE(true, 2018-01-01 01:23:45, null)):TIMESTAMP(0)),
> EXTRACT(FLAG(SECOND), $0)))
> expression is LogicalProject#6
> at
> org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:413)
> at
> org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule$ProjectReduceExpressionsRule.onMatch(ReduceExpressionsRule.java:290)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:317)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:556)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:415)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:252)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:127)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:211)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:198)
> ...
> {noformat}
> As far as I can tell, the issue is in
> {{ReduceExpressionRules#reduceExpressions}}: when the expression is partially
> reduced, the reduced expression lost its type nullability, which is not added
> back by the simplifier.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2290) Type mismatch during flattening
[
https://issues.apache.org/jira/browse/CALCITE-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-2290:
-
Labels: pull-request-available (was: )
> Type mismatch during flattening
> ---
>
> Key: CALCITE-2290
> URL: https://issues.apache.org/jira/browse/CALCITE-2290
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Laurent Goujon
>Priority: Major
> Labels: pull-request-available
>
> The following query causes Calcite not being able to perform SQL to Rel
> conversion:
> {code:sql}
> select (res1 = 'qwe') res2 from (select (case when (false) then null else
> 'qwe' end) res1 from (values(1)))
> {code}
>
> While adding the query to {{SqlToRelConverTest}}, the test generates the
> following output:
> {noformat}
> java.lang.AssertionError:
> type mismatch:
> ref:
> CHAR(3) CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary"
> input:
> CHAR(3) CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL
> at
> org.apache.calcite.test.SqlToRelConverterTest.testCaseFlatten(SqlToRelConverterTest.java:2786)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2209) Support loading JSON model file through URL
[ https://issues.apache.org/jira/browse/CALCITE-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-2209: - Labels: pull-request-available (was: ) > Support loading JSON model file through URL > --- > > Key: CALCITE-2209 > URL: https://issues.apache.org/jira/browse/CALCITE-2209 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Shuyi Chen >Assignee: Shuyi Chen >Priority: Major > Labels: pull-request-available > > Currently, Calcite only support loading JSON model file through inline or > local file. The Jira attemps to extend it to support loading JSON model file > through URL, so users can implement their own URLStreamHandlerFactory to read > the JSON model file from e.g., HDFS or etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-500) Ensure EnumerableJoin hashes the smallest input
[
https://issues.apache.org/jira/browse/CALCITE-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-500:
Labels: newbie pull-request-available (was: newbie)
> Ensure EnumerableJoin hashes the smallest input
> ---
>
> Key: CALCITE-500
> URL: https://issues.apache.org/jira/browse/CALCITE-500
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.0.0-incubating
>Reporter: Vladimir Sitnikov
>Assignee: Atri Sharma
>Priority: Major
> Labels: newbie, pull-request-available
> Attachments: lookup.png
>
>
> {{EnumerableJoin}} tries to put the smallest input the first, however when it
> comes to execution, Calcite creates lookup for _second_ input of join.
> It would be nice to ensure the lookup is created on the smallest input.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2298) Correlated SubQuery in Having generates error plan when correlated fields does not exist
[
https://issues.apache.org/jira/browse/CALCITE-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-2298:
-
Labels: pull-request-available (was: )
> Correlated SubQuery in Having generates error plan when correlated fields
> does not exist
>
>
> Key: CALCITE-2298
> URL: https://issues.apache.org/jira/browse/CALCITE-2298
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: godfrey he
>Priority: Major
> Labels: pull-request-available
>
> {code}
> @Test public void testDecorrelateWithUnresolvedField() throws Exception {
> final String sql = "select ename\n"
>+ "from sales.emp\n"
>+ "group by ename, deptno\n"
>+ "having max(sal) <= \n"
>+ " (select max(sal) from sales.emp_b where emp.job =
> emp_b.job group by ename)";
> checkSubQuery(sql).withLateDecorrelation(true).check();
> }
> {code}
> for now, we will get the following plan:
> {code}
> LogicalProject(ENAME=[$0])
> LogicalFilter(condition=[<=($2, $SCALAR_QUERY({
> LogicalProject(EXPR$0=[$1])
> LogicalAggregate(group=[{0}], EXPR$0=[MAX($1)])
> LogicalProject(ENAME=[$1], SAL=[$5])
> LogicalFilter(condition=[=($cor0.JOB, $2)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP_B]])
> }))])
> LogicalAggregate(group=[{0, 1}], agg#0=[MAX($2)])
> LogicalProject(ENAME=[$1], DEPTNO=[$7], SAL=[$5])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> However emp.job is not the grouping fields or the aggCall result.
> the expected result is throwing an Exception, like:
> {code}
> org.apache.calcite.runtime.CalciteContextException: From line 5, column 47 to
> line 5, column 50: Column 'JOB' not found in 'LogicalAggregate(group=[{0,
> 1}], agg#0=[MAX($2)])'
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2254) Test against IBM Java
[ https://issues.apache.org/jira/browse/CALCITE-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-2254: - Labels: pull-request-available (was: ) > Test against IBM Java > - > > Key: CALCITE-2254 > URL: https://issues.apache.org/jira/browse/CALCITE-2254 > Project: Calcite > Issue Type: Improvement >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Labels: pull-request-available > > IBM Java is open sourced and capable of being tested against with Travis CI > and Docker. We should test against IBM Java as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2194) Schema access authorization feature
[ https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-2194: - Labels: pull-request-available (was: ) > Schema access authorization feature > --- > > Key: CALCITE-2194 > URL: https://issues.apache.org/jira/browse/CALCITE-2194 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.16.0 >Reporter: Piotr Bojko >Assignee: Piotr Bojko >Priority: Minor > Labels: pull-request-available > > See: > [https://mail-archives.apache.org/mod_mbox/calcite-dev/201711.mbox/ajax/%3C6F6E52D4-6860-4384-A1CB-A2301D05394D%40apache.org%3E] > I've looked into the core and the notion of an user could be hard to achieved > now. > Though, I am able to implement the "hidden schema" feature through following > changes: > # JsonSchema - add a holder for the feature, boolean flag or flags field > with enum (CACHED which now exists as a separate flag - some deprecation > could be needed, HIDDEN) > # CalciteSchema - pass through of a flag > # RelOptSchema - pass through of a flag > # CalciteCatalogReader - pass through of a flag > # Other derivatives of RelOptSchema - mocked value, false > # RelOptTable and impl - pass through of a flag > # SqlValidatorImpl - validation whether object from hidden schema is used > (in the same places like validateAccess) > # ViewTableMacro.apply -> Schemas.analyzeView -> > CalcitePrepareImpl.analyzeView -> CalcitePrepareImpl.parse_ -> > CalcitePrepareImpl.CalcitePrepareImpl - this path of execution should build > SqlValidatorImpl which has the check from point 7 disabled- > Such feature could be useful for end users. > If the solution is ok - I can contribute it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2827) Allow CONVENTION.NONE planning with VolcanoPlanner
[ https://issues.apache.org/jira/browse/CALCITE-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779782#comment-16779782 ] Vladimir Sitnikov commented on CALCITE-2827: I agree with [~michaelmior]. It would be great to hear the intention behind the change. Otherwise we get yet another configuration option to test and support for unknown reason. > Allow CONVENTION.NONE planning with VolcanoPlanner > -- > > Key: CALCITE-2827 > URL: https://issues.apache.org/jira/browse/CALCITE-2827 > Project: Calcite > Issue Type: Task >Reporter: Siddharth Teotia >Assignee: Juhwan Kim >Priority: Minor > Labels: pull-request-available > Fix For: 1.19.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2827) Allow CONVENTION.NONE planning with VolcanoPlanner
[ https://issues.apache.org/jira/browse/CALCITE-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laurent Goujon resolved CALCITE-2827. - Resolution: Fixed Fix Version/s: 1.19.0 > Allow CONVENTION.NONE planning with VolcanoPlanner > -- > > Key: CALCITE-2827 > URL: https://issues.apache.org/jira/browse/CALCITE-2827 > Project: Calcite > Issue Type: Task >Reporter: Siddharth Teotia >Assignee: Juhwan Kim >Priority: Minor > Labels: pull-request-available > Fix For: 1.19.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CALCITE-2827) Allow CONVENTION.NONE planning with VolcanoPlanner
[ https://issues.apache.org/jira/browse/CALCITE-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laurent Goujon reassigned CALCITE-2827: --- Assignee: Juhwan Kim > Allow CONVENTION.NONE planning with VolcanoPlanner > -- > > Key: CALCITE-2827 > URL: https://issues.apache.org/jira/browse/CALCITE-2827 > Project: Calcite > Issue Type: Task >Reporter: Siddharth Teotia >Assignee: Juhwan Kim >Priority: Minor > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2827) Allow CONVENTION.NONE planning with VolcanoPlanner
[ https://issues.apache.org/jira/browse/CALCITE-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779769#comment-16779769 ] Laurent Goujon commented on CALCITE-2827: - Use case is to use volcano planner for doing cost based optimization without changing convention. > Allow CONVENTION.NONE planning with VolcanoPlanner > -- > > Key: CALCITE-2827 > URL: https://issues.apache.org/jira/browse/CALCITE-2827 > Project: Calcite > Issue Type: Task >Reporter: Siddharth Teotia >Priority: Minor > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2597) RelDataTypeImpl: digest can not describe a type completely
[ https://issues.apache.org/jira/browse/CALCITE-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-2597: - Summary: RelDataTypeImpl: digest can not describe a type completely (was: RelDataTypeImpl：digest can not describe a type completely.) > RelDataTypeImpl: digest can not describe a type completely > -- > > Key: CALCITE-2597 > URL: https://issues.apache.org/jira/browse/CALCITE-2597 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: huangjiatian >Priority: Minor > Labels: pull-request-available > Attachments: image-2018-09-28-13-00-16-440.png, > image-2018-09-28-13-11-43-515.png, image-2018-09-28-13-15-19-711.png, > image-2018-09-28-13-17-19-369.png > > > I met a strange question when i use Flink SQL API. > I found two difference type are considered equal. > !image-2018-09-28-13-11-43-515.png! > After debug, i found the hashCode method and equals method in RelRecordType > just consider "digest". > !image-2018-09-28-13-15-19-711.png! > But some time, "digest" can not describe a type completely, More information > in the "fieldList". > !image-2018-09-28-13-17-19-369.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2204) Volcano Planner may not choose the cheapest cost plan
[ https://issues.apache.org/jira/browse/CALCITE-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated CALCITE-2204: -- Labels: pull-request-available (was: ) > Volcano Planner may not choose the cheapest cost plan > -- > > Key: CALCITE-2204 > URL: https://issues.apache.org/jira/browse/CALCITE-2204 > Project: Calcite > Issue Type: Bug >Reporter: LeoWangLZ >Priority: Major > Labels: pull-request-available > > Volcano Planner will propagate the cost improvement to parents that one of > the inputs has the best plan. But it not propagate to all parents firstly, it > propagate one parent and go to the parents of parent. In the way, if one > parent may propagate to other parent on the same level, and the cost maybe > less than others, but when propagate the parent again, it will not propagate > because the cost is already calculated, and it's can't be less then the cost > of the self. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2157) ClickHouse dialect implementation
[ https://issues.apache.org/jira/browse/CALCITE-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated CALCITE-2157: -- Labels: pull-request-available (was: ) > ClickHouse dialect implementation > - > > Key: CALCITE-2157 > URL: https://issues.apache.org/jira/browse/CALCITE-2157 > Project: Calcite > Issue Type: New Feature > Components: jdbc-adapter >Reporter: Chris Baynes >Priority: Major > Labels: pull-request-available > > ClickHouse is a really fast columnar DBMS for OLAP: > [https://clickhouse.yandex/.|https://clickhouse.yandex/] > It has a jdbc adapter and uses mostly standard sql, though there are > differences (e.g. join syntax, datatypes, function name case-sensitivity). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-525) Exception-handling in built-in functions
[
https://issues.apache.org/jira/browse/CALCITE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated CALCITE-525:
-
Labels: pull-request-available (was: )
> Exception-handling in built-in functions
>
>
> Key: CALCITE-525
> URL: https://issues.apache.org/jira/browse/CALCITE-525
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
>
> The standard calls for certain built-in functions to throw exceptions.
> Examples:
> * 1 / 0
> * MOD(1, 0)
> * OVERLAY('foo' PLACING 'x' FROM -1)
> * 'x' NOT LIKE 'x' ESCAPE 'x'
> First, these exceptions should occur at run time. They should cause the
> current value to become null, or the row to be omitted, but should not abort
> the query. (Actual behavior TBD.)
> Second, EnumerableCalc does constant reduction and generates code like
> 'static final int X = 0 / 0'. This code blows up when the class is loaded. It
> should not. The code should give errors for each row, as described above.
> While fixing this bug, see SqlOperatorBaseTest.testArgumentBounds and remove
> restrictions related to /, MOD and OVERLAY, LIKE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2165) SqlCallingBinding.getOperandLiteralValue should ignore AssertionError
[ https://issues.apache.org/jira/browse/CALCITE-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated CALCITE-2165: -- Labels: pull-request-available (was: ) > SqlCallingBinding.getOperandLiteralValue should ignore AssertionError > - > > Key: CALCITE-2165 > URL: https://issues.apache.org/jira/browse/CALCITE-2165 > Project: Calcite > Issue Type: Bug >Reporter: Dian Fu >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2067) RexBuilder can't handle NaN,Infinity double constants
[
https://issues.apache.org/jira/browse/CALCITE-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated CALCITE-2067:
--
Labels: pull-request-available (was: )
> RexBuilder can't handle NaN,Infinity double constants
> -
>
> Key: CALCITE-2067
> URL: https://issues.apache.org/jira/browse/CALCITE-2067
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.13.0
>Reporter: Volodymyr Tkach
>Priority: Major
> Labels: pull-request-available
>
> Currently we are working in Drill to allow support for Nan an Infinity values
> .
> When using such values with functions we see the NumberFormatException
> exception.
> Query example: _select sin(cast('NaN' as float))_
> RexBuilder#clean and other RexBuilder's methods use BigDecimal for handling
> Double values, that's why we get NumberFormatException for nan,inf values.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2033) Support followed by in pattern definition for MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated CALCITE-2033:
--
Labels: match pull-request-available (was: match)
> Support followed by in pattern definition for MATCH_RECOGNIZE
> -
>
> Key: CALCITE-2033
> URL: https://issues.apache.org/jira/browse/CALCITE-2033
> Project: Calcite
> Issue Type: Bug
>Reporter: Dian Fu
>Priority: Major
> Labels: match, pull-request-available
>
> The [doc|https://docs.oracle.com/database/121/DWHSG/pattern.htm#DWHSG8986]
> has already defined pattern operator {{Concatenation}}. For example, pattern
> {{A B}} means that events matching pattern {{A}} and {{B}} should occur
> successively. There are also many use cases which require patterns to match
> events which not occur successively.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-1994) Elasticsearch5 not working using sqlline
[
https://issues.apache.org/jira/browse/CALCITE-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated CALCITE-1994:
--
Labels: pull-request-available (was: )
> Elasticsearch5 not working using sqlline
>
>
> Key: CALCITE-1994
> URL: https://issues.apache.org/jira/browse/CALCITE-1994
> Project: Calcite
> Issue Type: Bug
> Components: elasticsearch-adapter
>Affects Versions: 1.13.0
>Reporter: Kunwar Deep Singh
>Priority: Critical
> Labels: pull-request-available
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I have been trying to connect to elasticsearch 5.1.1 server using sqlline.
> The following error is generated.
> The following is the error:
> {noformat}
> java.lang.NoSuchMethodError:
> org.elasticsearch.transport.client.PreBuiltTransportClient.addPlugins(Ljava/util/Collectio
> n;Ljava/util/Collection;)Ljava/util/Collection;
> at
> org.elasticsearch.transport.client.PreBuiltTransportClient.(PreBuiltTransportClient.java:130)
> at
> org.elasticsearch.transport.client.PreBuiltTransportClient.(PreBuiltTransportClient.java:116)
> at
> org.elasticsearch.transport.client.PreBuiltTransportClient.(PreBuiltTransportClient.java:106)
> at
> org.apache.calcite.adapter.elasticsearch5.Elasticsearch5Schema.open(Elasticsearch5Schema.java:119)
> at
> org.apache.calcite.adapter.elasticsearch5.Elasticsearch5Schema.(Elasticsearch5Schema.java:74)
> at
> org.apache.calcite.adapter.elasticsearch5.Elasticsearch5SchemaFactory.create(Elasticsearch5SchemaFactory.java:56)
> at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:269)
> at
> org.apache.calcite.model.JsonCustomSchema.accept(JsonCustomSchema.java:45)
> at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:195)
> at org.apache.calcite.model.ModelHandler.(ModelHandler.java:87)
> at org.apache.calcite.jdbc.Driver$1.onConnectionInit(Driver.java:104)
> at
> org.apache.calcite.avatica.UnregisteredDriver.connect(UnregisteredDriver.java:139)
> at sqlline.DatabaseConnection.connect(DatabaseConnection.java:156)
> at sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:204)
> at sqlline.Commands.connect(Commands.java:1095)
> at sqlline.Commands.connect(Commands.java:1001)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-1926) Function names are unparsed quoted while PostgreSQL can only handle unquoted function names
[
https://issues.apache.org/jira/browse/CALCITE-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated CALCITE-1926:
--
Labels: Postgres pull-request-available (was: Postgres)
> Function names are unparsed quoted while PostgreSQL can only handle unquoted
> function names
> ---
>
> Key: CALCITE-1926
> URL: https://issues.apache.org/jira/browse/CALCITE-1926
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.13.0
>Reporter: Muhammad Gelbana
>Priority: Major
> Labels: Postgres, pull-request-available
>
> While working on a Drill plugin, Calcite unparsed a *JdbcRel* node and
> produced the following PostgreSQL query
> {code:sql}
> SELECT "TEMP( Test)( 535799381)( 0)"
> FROM (SELECT "STRPOS"("str1", 'BI') = 1 AS "TEMP( Test)( 535799381)( 0)"
> FROM "TestV1"."Calcs") AS "t"
> GROUP BY "TEMP( Test)( 535799381)( 0)"
> {code}
> The query fails due to a parsing exception, the reason is that the *STRPOS*
> function name is quoted using double quotes. I tried the query manually
> without quoting the function name and it executed successfully.
> I debugged through Calcite and found that the [this
> method|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/SqlUtil.java#L262]
> unparses the function name as a plain identifier which leads to the [quoting
> of the function
> name|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/SqlIdentifier.java?deDup474625=1#L287]
> if the dialect supports it.
> Drill uses Calcite v1.4 but as I compared it with the master branch, I found
> them identical.
> I haven't tried that with custom functions yet.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-1962) SqlOrderBy unparse ignores dialect.
[
https://issues.apache.org/jira/browse/CALCITE-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated CALCITE-1962:
--
Labels: pull-request-available (was: )
> SqlOrderBy unparse ignores dialect.
> ---
>
> Key: CALCITE-1962
> URL: https://issues.apache.org/jira/browse/CALCITE-1962
> Project: Calcite
> Issue Type: Bug
>Reporter: Paul O'Riordan
>Priority: Major
> Labels: pull-request-available
>
> Given the following code:
> {noformat}
> final SqlParser.ConfigBuilder configBuilder =
> SqlParser.configBuilder();
> configBuilder.setLex(Lex.MYSQL);
> final SqlParser.Config config = configBuilder.build();
> final SqlParser parser = SqlParser.create(str, config);
> final SqlNode parsedStatement = parser.parseQuery("select id from
> Test limit 1");
> final SqlDialect mysqlDialect = new SqlDialect(DatabaseProduct.MYSQL,
> "mysql", "`", NullCollation.LAST);
> final SqlPrettyWriter spw1 = new SqlPrettyWriter(mysqlDialect);
> System.out.println(spw1.format(parsedStatement));
> {noformat}
> The output is:
> {noformat}
> SELECT `id`
> FROM `Test`
> FETCH NEXT 1 ROWS ONLY
> {noformat}
> Expected output:
> {noformat}
> SELECT `id`
> FROM `Test`
> LIMIT 1
> {noformat}
> Suggested fix:
> {noformat}
> diff --git a/core/src/main/java/org/apache/calcite/sql/SqlOrderBy.java
> b/core/src/main/java/org/apache/calcite/sql/SqlOrderBy.java
> index 421b9e21d..b26ffd67b 100644
> --- a/core/src/main/java/org/apache/calcite/sql/SqlOrderBy.java
> +++ b/core/src/main/java/org/apache/calcite/sql/SqlOrderBy.java
> @@ -95,26 +95,7 @@ public void unparse(
> unparseListClause(writer, orderBy.orderList);
> writer.endList(listFrame);
>}
> - if (orderBy.offset != null) {
> -final SqlWriter.Frame frame2 =
> -writer.startList(SqlWriter.FrameTypeEnum.OFFSET);
> -writer.newlineAndIndent();
> -writer.keyword("OFFSET");
> -orderBy.offset.unparse(writer, -1, -1);
> -writer.keyword("ROWS");
> -writer.endList(frame2);
> - }
> - if (orderBy.fetch != null) {
> -final SqlWriter.Frame frame3 =
> -writer.startList(SqlWriter.FrameTypeEnum.FETCH);
> -writer.newlineAndIndent();
> -writer.keyword("FETCH");
> -writer.keyword("NEXT");
> -orderBy.fetch.unparse(writer, -1, -1);
> -writer.keyword("ROWS");
> -writer.keyword("ONLY");
> -writer.endList(frame3);
> - }
> + writer.fetchOffset(orderBy.fetch, orderBy.offset);
>writer.endList(frame);
> }
>}
> {noformat}
> See PR: https://github.com/apache/calcite/pull/525
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-1956) Allow MultiJoin to contain multiple FULL joins
[ https://issues.apache.org/jira/browse/CALCITE-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated CALCITE-1956: -- Labels: pull-request-available (was: ) > Allow MultiJoin to contain multiple FULL joins > -- > > Key: CALCITE-1956 > URL: https://issues.apache.org/jira/browse/CALCITE-1956 > Project: Calcite > Issue Type: Bug >Reporter: MinJi Kim >Priority: Major > Labels: pull-request-available > > JoniToMultiJoinRule collapses multiple INNER joins into a single MultiJoin. > I was wondering if all the joins are full outer joins, couldn't we use the > same logic to allow MultiJoins to contains multiple FULL joins? This would > allow LoptOptimizeJoinRule to re-order full outer joins, just like inner > joins. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-1882) Can't obtain the user defined aggregate function such as sum,avg by calcite
[
https://issues.apache.org/jira/browse/CALCITE-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated CALCITE-1882:
--
Labels: pull-request-available (was: )
> Can't obtain the user defined aggregate function such as sum,avg by calcite
> ---
>
> Key: CALCITE-1882
> URL: https://issues.apache.org/jira/browse/CALCITE-1882
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.12.0
>Reporter: yuemeng
>Assignee: yuemeng
>Priority: Critical
> Labels: pull-request-available
>
> If we want to register a sum or avg aggregate function to deal with different
> data type such as sum(double) ,we implement a SqlUserDefinedAggFunction and
> register with name sum,but when we execute a sql like:
> {code}
> select id,sum(payment) from table test group by id
> {code}
> in fact,it always give the SqlSumAggFunction function which builtin by
> calcite,never find the exactly function which we register by ourself.
> During sql parse process,method createCall in SqlAbstractParserImpl will be
> called,
> {code}
> protected SqlCall createCall(
> SqlIdentifier funName,
> SqlParserPos pos,
> SqlFunctionCategory funcType,
> SqlLiteral functionQualifier,
> SqlNode[] operands) {
> SqlOperator fun = null;
> // First, try a half-hearted resolution as a builtin function.
> // If we find one, use it; this will guarantee that we
> // preserve the correct syntax (i.e. don't quote builtin function
> /// name when regenerating SQL).
> if (funName.isSimple()) {
> final List list = Lists.newArrayList();
> opTab.lookupOperatorOverloads(funName, funcType, SqlSyntax.FUNCTION,
> list);//we lookup in SqlStdOperatorTable,and always find buidin function for
> sum ,avg .eg
> if (list.size() == 1) {
> fun = list.get(0);
> }
> }
> // Otherwise, just create a placeholder function. Later, during
> // validation, it will be resolved into a real function reference.
> if (fun == null) {
> fun = new SqlUnresolvedFunction(funName, null, null, null, null,
> funcType);
> }
> return fun.createCall(functionQualifier, pos, operands);
> }
> {code}
> but the problem will be appear in deriveType,because of we get the
> SqlSumAggFunction previously,and the sqlKind of SqlSumAggFunction is AVG,but
> the sqlKind of sql user defined agg function (sum) which we register by
> ourself is OTHER_FUNCTION,so it filter out our sum function.
> {code}
> private static Iterator
> filterOperatorRoutinesByKind(Iterator routines,
> final SqlKind sqlKind) {
> return Iterators.filter(routines,
> new PredicateImpl() {
> public boolean test(SqlOperator input) {
> return input.getKind() == sqlKind;
> }
> });
> }
> {code}
> that cause we never obtain sum function which registered by user .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-1940) Implement dialect specific support for sequences
[ https://issues.apache.org/jira/browse/CALCITE-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated CALCITE-1940: -- Labels: pull-request-available (was: ) > Implement dialect specific support for sequences > > > Key: CALCITE-1940 > URL: https://issues.apache.org/jira/browse/CALCITE-1940 > Project: Calcite > Issue Type: Improvement >Reporter: Christian Beikov >Priority: Major > Labels: pull-request-available > > The Calcite parser and validator already supports sequences but the push down > to the JDBC level is currently limited. SInce sequences are not supported on > all DBMS every sql dialect should have the possibility to render it's own way > of extracting sequence information or incrementing the value. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-1681) Provide a way to copy RelNode trees between clusters
[ https://issues.apache.org/jira/browse/CALCITE-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated CALCITE-1681: -- Labels: pull-request-available (was: ) > Provide a way to copy RelNode trees between clusters > > > Key: CALCITE-1681 > URL: https://issues.apache.org/jira/browse/CALCITE-1681 > Project: Calcite > Issue Type: Improvement >Reporter: Remus Rusanu >Assignee: Remus Rusanu >Priority: Major > Labels: pull-request-available > > In Hive we cache materialized view plans and reuse the cached plans in > queries. For this we need a way to do deep clone copy of a RelNode tree from > one RelOptCluster to another. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2597) RelDataTypeImpl：digest can not describe a type completely.
[ https://issues.apache.org/jira/browse/CALCITE-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated CALCITE-2597: -- Labels: pull-request-available (was: ) > RelDataTypeImpl：digest can not describe a type completely. > -- > > Key: CALCITE-2597 > URL: https://issues.apache.org/jira/browse/CALCITE-2597 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: huangjiatian >Priority: Minor > Labels: pull-request-available > Attachments: image-2018-09-28-13-00-16-440.png, > image-2018-09-28-13-11-43-515.png, image-2018-09-28-13-15-19-711.png, > image-2018-09-28-13-17-19-369.png > > > I met a strange question when i use Flink SQL API. > I found two difference type are considered equal. > !image-2018-09-28-13-11-43-515.png! > After debug, i found the hashCode method and equals method in RelRecordType > just consider "digest". > !image-2018-09-28-13-15-19-711.png! > But some time, "digest" can not describe a type completely, More information > in the "fieldList". > !image-2018-09-28-13-17-19-369.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2641) DATE and TIMESTAMP arguments to user-defined table function
[
https://issues.apache.org/jira/browse/CALCITE-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated CALCITE-2641:
--
Labels: pull-request-available (was: )
> DATE and TIMESTAMP arguments to user-defined table function
> ---
>
> Key: CALCITE-2641
> URL: https://issues.apache.org/jira/browse/CALCITE-2641
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0, 1.18.0
>Reporter: Piotr Bojko
>Priority: Major
> Labels: pull-request-available
>
> I am trying to create UDF with java.sql.Timestamp as a parameter:
> {code:java}
> public static QueryableTable getTable(
> @Parameter(name = "Projection") String projection,
> @Parameter(name = "Query") String query,
> @Parameter(name = "Test Timestamp") Timestamp
> timestamp)
> {code}
> But when using following UDF like this:
> {code:java}
> SELECT * FROM TABLE(MYUDF('ID','', TIMESTAMP '2013-01-01 01:01:01'))
> {code}
> I've got following exception and wondering whether I am missing something or
> having date/time as a parameter is not fully supported yet?
> {noformat}
> [INFO] [talledLocalContainer] java.lang.AssertionError: value 2013-01-01
> 01:01:01 does not match type class java.sql.Timestamp
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.ConstantExpression.(ConstantExpression.java:49)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:588)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:278)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:37)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.GotoStatement.accept(GotoStatement.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.optimize(BlockBuilder.java:438)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.linq4j.tree.BlockBuilder.toBlock(BlockBuilder.java:322)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.coerce(SqlUserDefinedTableMacro.java:190)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableMacro.convertArguments(SqlUserDefinedTableMacro.java:110)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlUserDefinedTableFunction.getRowType(SqlUserDefinedTableFunction.java:70)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.ProcedureNamespace.validateImpl(ProcedureNamespace.java:62)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3036)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateFrom(SqlValidatorImpl.java:3018)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3288)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:971)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:950)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:216)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:925)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:629)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:553)
> [INFO] [talledLocalContainer] at
> org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:264)
> [INFO] [talledLocalContainer] at
>
[jira] [Updated] (CALCITE-2824) Fix invalid usage of RexExecutorImpl
[ https://issues.apache.org/jira/browse/CALCITE-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated CALCITE-2824: -- Labels: pull-request-available (was: ) > Fix invalid usage of RexExecutorImpl > > > Key: CALCITE-2824 > URL: https://issues.apache.org/jira/browse/CALCITE-2824 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Siddharth Teotia >Priority: Major > Labels: pull-request-available > > There's an attempt in SubstitutionVisitor of casting RexExecutor into a > RexExecutorImpl instance, which might break when a different executor is used > for planning -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2667) sql2rel fails on join between table function and other table
[
https://issues.apache.org/jira/browse/CALCITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated CALCITE-2667:
--
Labels: pull-request-available (was: )
> sql2rel fails on join between table function and other table
>
>
> Key: CALCITE-2667
> URL: https://issues.apache.org/jira/browse/CALCITE-2667
> Project: Calcite
> Issue Type: Bug
>Reporter: Piotr Bojko
>Priority: Major
> Labels: pull-request-available
>
> Bug reproduction is here -
> https://github.com/ptrbojko/calcite/tree/bug/CALCITE-2667
> {noformat}
> > java.lang.AssertionError: Field ordinal 2 is invalid for type
> > 'RecordType(VARCHAR TYPE, VARCHAR CODEVALUE)'
> > at
> > org.apache.calcite.rex.RexBuilder.makeFieldAccess(RexBuilder.java:188)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertIdentifier(SqlToRelConverter.java:3616)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.access$2100(SqlToRelConverter.java:215)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4691)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:334)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:204)
> > at
> > org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:63)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4682)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:3987)
> > at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4551)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectList(SqlToRelConverter.java:3830)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:668)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:625)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3074)
> > at
> > org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:561)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:265)
> > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:772)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:636)
> > at
> > org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:606)
> > at
> > org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:229)
> > at
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
> > at
> > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> > at
> > org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> > at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> > at net.hydromatic.quidem.Quidem.access$2800(Quidem.java:54)
> > at
> > net.hydromatic.quidem.Quidem$ContextImpl.checkResult(Quidem.java:1747)
> > at
> > net.hydromatic.quidem.Quidem$CheckResultCommand.execute(Quidem.java:1078)
> > at
> > net.hydromatic.quidem.Quidem$CompositeCommand.execute(Quidem.java:1548)
> > at net.hydromatic.quidem.Quidem.execute(Quidem.java:216)
> > at org.apache.calcite.test.QuidemTest.checkRun(QuidemTest.java:161)
> > at org.apache.calcite.test.QuidemTest.test(QuidemTest.java:209)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:498)
> > at
> > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> > at
> > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> > at
> > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> > at
> >
[jira] [Commented] (CALCITE-1703) Query with BETWEEN or AGGREGATE functions on TIMESTAMP column throws ClassCastException
[
https://issues.apache.org/jira/browse/CALCITE-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779712#comment-16779712
]
Kevin Risden commented on CALCITE-1703:
---
[~vlsi] - last comment on PR was planning to merge. Still the case?
> Query with BETWEEN or AGGREGATE functions on TIMESTAMP column throws
> ClassCastException
> ---
>
> Key: CALCITE-1703
> URL: https://issues.apache.org/jira/browse/CALCITE-1703
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0
> Environment: Any
>Reporter: Gangadhar Kairi
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.19.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Getting below error while executing the query on timestamp columns with
> BETWEEN or AGGREGATE function operator.
> {noformat}
> java.sql.SQLException: Error while executing SQL "select * from "DATE" where
> "JOINTIMES" < '2017-03-16 18:04:07.034'": java.sql.Timestamp cannot be cast
> to java.lang.Long
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> at
> org.apache.calcite.test.CsvTest.testTimestampGTCheck(CsvTest.java:617)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to
> java.lang.Long
> at Baz$1$1.moveNext(Unknown Source)
> at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:664)
> at org.apache.calcite.linq4j.Linq4j.enumeratorIterator(Linq4j.java:98)
> at
> org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:89)
> at
> org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:196)
> at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> {noformat}
> I could able to reproduce this issues in CsvTests.
>
> Fire a test with query "select * from \"DATE\" where \"JOINTIMES\" BETWEEN '"
> + from + "' and '" + to + "'" you will see test failing with exception.
> Root cause and fix:
> Timestamp datatype needs to be handled in the same way as the Date datatype.
> In
[jira] [Updated] (CALCITE-2697) Better handling bindable params pushed down to JDBC schema
[ https://issues.apache.org/jira/browse/CALCITE-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated CALCITE-2697: -- Labels: pull-request-available (was: ) > Better handling bindable params pushed down to JDBC schema > -- > > Key: CALCITE-2697 > URL: https://issues.apache.org/jira/browse/CALCITE-2697 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Piotr Bojko >Priority: Major > Labels: pull-request-available > > This is a follow up for CALCITE-563 . > Current DataContext has insufficient info about original bind param value and > type setup by an end user. > I would go with enriching DataContext with more information from TypedValue > wrappers for params. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-1703) Query with BETWEEN or AGGREGATE functions on TIMESTAMP column throws ClassCastException
[
https://issues.apache.org/jira/browse/CALCITE-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated CALCITE-1703:
--
Fix Version/s: 1.19.0
> Query with BETWEEN or AGGREGATE functions on TIMESTAMP column throws
> ClassCastException
> ---
>
> Key: CALCITE-1703
> URL: https://issues.apache.org/jira/browse/CALCITE-1703
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0
> Environment: Any
>Reporter: Gangadhar Kairi
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.19.0
>
>
> Getting below error while executing the query on timestamp columns with
> BETWEEN or AGGREGATE function operator.
> {noformat}
> java.sql.SQLException: Error while executing SQL "select * from "DATE" where
> "JOINTIMES" < '2017-03-16 18:04:07.034'": java.sql.Timestamp cannot be cast
> to java.lang.Long
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> at
> org.apache.calcite.test.CsvTest.testTimestampGTCheck(CsvTest.java:617)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to
> java.lang.Long
> at Baz$1$1.moveNext(Unknown Source)
> at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:664)
> at org.apache.calcite.linq4j.Linq4j.enumeratorIterator(Linq4j.java:98)
> at
> org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:89)
> at
> org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:196)
> at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> {noformat}
> I could able to reproduce this issues in CsvTests.
>
> Fire a test with query "select * from \"DATE\" where \"JOINTIMES\" BETWEEN '"
> + from + "' and '" + to + "'" you will see test failing with exception.
> Root cause and fix:
> Timestamp datatype needs to be handled in the same way as the Date datatype.
> In {{RexToLixTranslator.convert()}} method and in
> {{PhysTypeImpl.fieldReference()}} method.
--
This message was sent by Atlassian JIRA
[jira] [Updated] (CALCITE-1703) Query with BETWEEN or AGGREGATE functions on TIMESTAMP column throws ClassCastException
[
https://issues.apache.org/jira/browse/CALCITE-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated CALCITE-1703:
--
Labels: pull-request-available (was: )
> Query with BETWEEN or AGGREGATE functions on TIMESTAMP column throws
> ClassCastException
> ---
>
> Key: CALCITE-1703
> URL: https://issues.apache.org/jira/browse/CALCITE-1703
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0
> Environment: Any
>Reporter: Gangadhar Kairi
>Priority: Major
> Labels: pull-request-available
>
> Getting below error while executing the query on timestamp columns with
> BETWEEN or AGGREGATE function operator.
> {noformat}
> java.sql.SQLException: Error while executing SQL "select * from "DATE" where
> "JOINTIMES" < '2017-03-16 18:04:07.034'": java.sql.Timestamp cannot be cast
> to java.lang.Long
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> at
> org.apache.calcite.test.CsvTest.testTimestampGTCheck(CsvTest.java:617)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to
> java.lang.Long
> at Baz$1$1.moveNext(Unknown Source)
> at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:664)
> at org.apache.calcite.linq4j.Linq4j.enumeratorIterator(Linq4j.java:98)
> at
> org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:89)
> at
> org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:196)
> at
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> {noformat}
> I could able to reproduce this issues in CsvTests.
>
> Fire a test with query "select * from \"DATE\" where \"JOINTIMES\" BETWEEN '"
> + from + "' and '" + to + "'" you will see test failing with exception.
> Root cause and fix:
> Timestamp datatype needs to be handled in the same way as the Date datatype.
> In {{RexToLixTranslator.convert()}} method and in
> {{PhysTypeImpl.fieldReference()}} method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2593) Sometimes fails to plan when a RelNode transform multiple collations to single collation
[
https://issues.apache.org/jira/browse/CALCITE-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated CALCITE-2593:
--
Labels: pull-request-available (was: )
> Sometimes fails to plan when a RelNode transform multiple collations to
> single collation
>
>
> Key: CALCITE-2593
> URL: https://issues.apache.org/jira/browse/CALCITE-2593
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
>
> Sample SQL:
> {code:java}
> select sum(X + 1) filter (where Y) as "SET" from (values (1, TRUE), (2,
> TRUE)) AS t(X, Y) limit 10{code}
> Error log:
> {code:java}
> java.lang.RuntimeException: exception while executing [select sum(X + 1)
> filter (where Y) as "SET" from (values (1, TRUE), (2, TRUE)) AS t(X, Y) limit
> 10] at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1366)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1339)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1302)
> at
> org.apache.calcite.test.JdbcTest.testWithinGroupClause5(JdbcTest.java:6736)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at
> org.junit.runners.ParentRunner.run(ParentRunner.java:363) at
> org.junit.runner.JUnitCore.run(JUnitCore.java:137) at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.RuntimeException: With materializationsEnabled=false,
> limit=0 at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:573) at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1362)
> ... 25 more Caused by: java.sql.SQLException: Error while executing SQL
> "select sum(X + 1) filter (where Y) as "SET" from (values (1, TRUE), (2,
> TRUE)) AS t(X, Y) limit 10": Node [rel#22:Subset#3.ENUMERABLE.[]] could not
> be implemented; planner state: Root: rel#22:Subset#3.ENUMERABLE.[] Original
> rel: LogicalSort(subset=[rel#22:Subset#3.ENUMERABLE.[]], fetch=[10]):
> rowcount = 1.0, cumulative cost = {1.0 rows, 4.0 cpu, 0.0 io}, id = 17
> LogicalAggregate(subset=[rel#16:Subset#2.NONE.[]], group=[{}], SET=[SUM($0)
> FILTER $1]): rowcount = 1.0, cumulative cost = {1.1375000476837158 rows, 0.0
> cpu, 0.0 io}, id = 15 LogicalProject(subset=[rel#14:Subset#1.NONE.[1]],
> $f0=[+($0, 1)], Y=[$1]): rowcount = 2.0, cumulative cost = {2.0 rows, 4.0
> cpu, 0.0 io}, id = 13 LogicalValues(subset=[rel#12:Subset#0.NONE.[]],
> tuples=[[{ 1, true }, { 2, true }]]): rowcount = 2.0, cumulative cost = {2.0
> rows, 1.0 cpu, 0.0 io}, id = 1 Sets: Set#0, type: RecordType(INTEGER X,
> BOOLEAN Y) rel#12:Subset#0.NONE.[], best=null, importance=0.6561
> rel#1:LogicalValues.NONE.[[0, 1], [1]](type=RecordType(INTEGER X, BOOLEAN
> Y),tuples=[{ 1, true }, { 2, true }]), rowcount=2.0, cumulative cost={inf}
> rel#37:Subset#0.ENUMERABLE.[], best=rel#36, importance=0.32805
> rel#36:EnumerableValues.ENUMERABLE.[[0, 1], [1]](type=RecordType(INTEGER X,
> BOOLEAN Y),tuples=[{ 1, true }, { 2, true }]), rowcount=2.0, cumulative
> cost={2.0 rows, 1.0 cpu, 0.0 io} Set#1, type: RecordType(INTEGER $f0, BOOLEAN
> Y)
[jira] [Updated] (CALCITE-2751) MetadataCycleException not handled in VolcanoRelMetadataProvider
[ https://issues.apache.org/jira/browse/CALCITE-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated CALCITE-2751: -- Labels: pull-request-available (was: ) > MetadataCycleException not handled in VolcanoRelMetadataProvider > > > Key: CALCITE-2751 > URL: https://issues.apache.org/jira/browse/CALCITE-2751 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Steven Phillips >Priority: Major > Labels: pull-request-available > > If the RelSubset has no best RelNode, we iterate through all of the RelNodes > until we find one that has appropriate Metadata. But if the RelNode we choose > has already been visited, the CyclicMetadataException is thrown, but not > caught. We should catch the exception and try again on another RelNode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2648) Output collation of EnumerableWindow is not consistent with its implementation
[
https://issues.apache.org/jira/browse/CALCITE-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated CALCITE-2648:
--
Labels: pull-request-available (was: )
> Output collation of EnumerableWindow is not consistent with its implementation
> --
>
> Key: CALCITE-2648
> URL: https://issues.apache.org/jira/browse/CALCITE-2648
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.17.0
>Reporter: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
> Attachments:
> postgresql_96_doesnt_care_to_keep_collation_for_project_over_expression.png
>
>
> Here is a case:
> {code:sql}
> select x, COUNT(*) OVER (PARTITION BY x) from (values (20), (35)) as t(x)
> ORDER BY x
> {code}
> Final plan:
> {code:java}
> EnumerableWindow(window#0=[window(partition {0} order by [] range between
> UNBOUNDED PRECEDING and UNBOUNDED FOLLOWING aggs [COUNT()])])
> EnumerableValues(tuples=[[{ 20 }, { 35 }]])
> {code}
> Output rows:
> {code:java}
> X |EXPR$1 |
> ---|---|
> 35 |1 |
> 20 |1 |
> {code}
> EnumerableWindow is supposed to preserve input collations, as a result
> EnumerableSort is ignored. However the implementation of EnumerableWindow
> generates non-ordered output (when PARTITION BY clause is used).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2801) Check input type in AggregateUnionAggregateRule when remove the bottom Aggregate
[
https://issues.apache.org/jira/browse/CALCITE-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated CALCITE-2801:
--
Labels: pull-request-available (was: )
> Check input type in AggregateUnionAggregateRule when remove the bottom
> Aggregate
>
>
> Key: CALCITE-2801
> URL: https://issues.apache.org/jira/browse/CALCITE-2801
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Hequn Cheng
>Assignee: Hequn Cheng
>Priority: Major
> Labels: pull-request-available
>
> In {{AggregateUnionAggregateRule}}, we may remove the bottom Aggregate and
> use it's input as the new input of Union directly. However, the bottom
> Aggregate and it's input may not share the same row type. As Union requires
> all inputs with a same row type, once we remove the bottom Aggregate, an
> exception will be thrown.
> The exception can be reproduced by the following test:
> {code:java}
> @Test public void testPullAggregateThroughUnion() {
> HepProgram program = new HepProgramBuilder()
> .addRuleInstance(AggregateProjectMergeRule.INSTANCE)
> .addRuleInstance(AggregateUnionAggregateRule.INSTANCE)
> .build();
> final String sql = "select job, deptno from"
> + " (select job, deptno from emp as e1"
> + " group by job, deptno"
> + " union all"
> + " select job, deptno from emp as e2"
> + " group by job, deptno)"
> + " group by job, deptno";
> sql(sql).with(program).check();
> }
> {code}
> {code:java}
> java.lang.IllegalArgumentException: Cannot compute compatible row type for
> arguments to set op: RecordType(VARCHAR(10) JOB, INTEGER DEPTNO),
> RecordType(INTEGER EMPNO, VARCHAR(20) ENAME, VARCHAR(10) JOB, INTEGER MGR,
> TIMESTAMP(0) HIREDATE, INTEGER SAL, INTEGER COMM, INTEGER DEPTNO, BOOLEAN
> SLACKER)
> at org.apache.calcite.rel.core.SetOp.deriveRowType(SetOp.java:111)
> at
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:222)
> at
> org.apache.calcite.tools.RelBuilder$Frame.(RelBuilder.java:2378)
> at
> org.apache.calcite.tools.RelBuilder$Frame.(RelBuilder.java:2363)
> at org.apache.calcite.tools.RelBuilder.push(RelBuilder.java:260)
> at org.apache.calcite.tools.RelBuilder.setOp(RelBuilder.java:1559)
> at org.apache.calcite.tools.RelBuilder.union(RelBuilder.java:1579)
> at org.apache.calcite.tools.RelBuilder.union(RelBuilder.java:1569)
> at
> org.apache.calcite.rel.rules.AggregateUnionAggregateRule.onMatch(AggregateUnionAggregateRule.java:130)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:319)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:559)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:418)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:255)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:127)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:214)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:201)
> at
> org.apache.calcite.test.RelOptTestBase.checkPlanning(RelOptTestBase.java:206)
> at
> org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:334)
> at
> org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:317)
> at org.apache.calcite.test.RelOptRulesTest.testPullAggregateThroughUnion
> {code}
> I see two option to solve the problem:
> - Check the input type in {{AggregateUnionAggregateRule}} and exit the rule
> directly.
> - Add a Project with a same row type to the bottom Aggregate.
> What do you guys think? Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2785) In EnumerableAggregate, wrong result produced If there are sorted aggregates and non-sorted aggregates at the same time
[
https://issues.apache.org/jira/browse/CALCITE-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated CALCITE-2785:
--
Labels: pull-request-available (was: )
> In EnumerableAggregate, wrong result produced If there are sorted aggregates
> and non-sorted aggregates at the same time
> ---
>
> Key: CALCITE-2785
> URL: https://issues.apache.org/jira/browse/CALCITE-2785
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.18.0
>Reporter: Hongze Zhang
>Assignee: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
>
> SQL:
> {code:sql}
> WITH tab(X) AS (values 1, 2, 1)
> SELECT COLLECT(x), COLLECT(x) WITHIN GROUP (ORDER BY 1) FROM tab
> {code}
> Result:
> {code}
> EXPR$0 |EXPR$1 |
> ---||
>|[1,2,1] |
> {code}
> Correct result:
> {code}
> EXPR$0 |EXPR$1 |
> ---||
> [1,2,1]|[1,2,1] |
> {code}
> The problem is introduced by
> [CALCITE-2224|https://issues.apache.org/jira/browse/CALCITE-2224].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2820) Add a version of AggregateReduceFunctionsRule that does not reduce SUm -> SUM0
[ https://issues.apache.org/jira/browse/CALCITE-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated CALCITE-2820: -- Labels: pull-request-available (was: ) > Add a version of AggregateReduceFunctionsRule that does not reduce SUm -> SUM0 > -- > > Key: CALCITE-2820 > URL: https://issues.apache.org/jira/browse/CALCITE-2820 > Project: Calcite > Issue Type: Task > Components: core >Reporter: Siddharth Teotia >Priority: Minor > Labels: pull-request-available > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2819) Add a version of LoptOptimizeJoinRule that uses the first ordering it finds
[ https://issues.apache.org/jira/browse/CALCITE-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated CALCITE-2819: -- Labels: pull-request-available (was: ) > Add a version of LoptOptimizeJoinRule that uses the first ordering it finds > --- > > Key: CALCITE-2819 > URL: https://issues.apache.org/jira/browse/CALCITE-2819 > Project: Calcite > Issue Type: Task > Components: core >Reporter: Siddharth Teotia >Priority: Minor > Labels: pull-request-available > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2742) Update RexImpTable to user DataContext to retrieve USER and SYSTEM_USER
[ https://issues.apache.org/jira/browse/CALCITE-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-2742: Labels: pull-request-available (was: ) > Update RexImpTable to user DataContext to retrieve USER and SYSTEM_USER > --- > > Key: CALCITE-2742 > URL: https://issues.apache.org/jira/browse/CALCITE-2742 > Project: Calcite > Issue Type: Improvement >Reporter: Jacques Nadeau >Assignee: Jacques Nadeau >Priority: Major > Labels: pull-request-available > > Right now, USER and SYSTEM_USER are hardcoded to "sa" and the system property > of user.name. Let's update them to use the DataContext system like the other > similar types of values. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2879) Improve filter condition in Join
[
https://issues.apache.org/jira/browse/CALCITE-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779560#comment-16779560
]
Julian Hyde commented on CALCITE-2879:
--
-1
I think there's already a way to do this, using pulled up predicates. It's
superior to your "structural" approach, because it also allows predicates that
have bubbled up from the sources.
> Improve filter condition in Join
>
>
> Key: CALCITE-2879
> URL: https://issues.apache.org/jira/browse/CALCITE-2879
> Project: Calcite
> Issue Type: Improvement
>Reporter: yuqi
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, filter condition in join have not been optimized very well, let's
> take a simple example
> {code:sql}
> select a.id, b.name from Ta a inner join Tb b on a.id = b.id and a.id < 5;
> {code}
> now, only a.id < 5 can push down, however, as for the sql above,
> we can infer a.id < 5 and b.id < 5 and both of them can push down.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2864) Add the JSON_DEPTH function
[
https://issues.apache.org/jira/browse/CALCITE-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779566#comment-16779566
]
Julian Hyde commented on CALCITE-2864:
--
Was a parser change really needed? JSON_DEPTH has conventional function syntax.
> Add the JSON_DEPTH function
> ---
>
> Key: CALCITE-2864
> URL: https://issues.apache.org/jira/browse/CALCITE-2864
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.19.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Returns the maximum depth of a JSON document. Returns {{NULL}} if the
> argument is {{NULL}}. An error occurs if the argument is not a valid JSON
> document.
> An empty array, empty object, or scalar value has depth 1. A nonempty array
> containing only elements of depth 1 or nonempty object containing only member
> values of depth 1 has depth 2. Otherwise, a JSON document has depth greater
> than 2.
>
> Example Sql:
> SELECT JSON_DEPTH(v) AS c1
> ,JSON_DEPTH(JSON_VALUE(v, 'lax $.b' ERROR ON ERROR)) AS c2
> ,JSON_DEPTH(JSON_VALUE(v, 'strict $.a[0]' ERROR ON ERROR)) AS c3
> ,JSON_DEPTH(JSON_VALUE(v, 'strict $.a[1]' ERROR ON ERROR)) AS c4
> FROM (VALUES ('
> {"a": [10, true],"b": "[10, true]"}
> ')) AS t(v)
> limit 10;
> Result:
> c1 c2 c3 c4
> == == == ==
> 3 2 1 1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2787) Json aggregate calls with different null clause get incorrectly merged during converting from SQL to relational algebra
[
https://issues.apache.org/jira/browse/CALCITE-2787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779368#comment-16779368
]
Hongze Zhang edited comment on CALCITE-2787 at 2/27/19 4:14 PM:
Fixed in
[82ab280b492c737c1668360a4a434718465ad013|https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=82ab280b492c737c1668360a4a434718465ad013].
was (Author: zhztheplayer):
Fixed in
[5ada462e6f792deee7185ad2df8ec58380061d59|https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=5ada462e6f792deee7185ad2df8ec58380061d59].
> Json aggregate calls with different null clause get incorrectly merged
> during converting from SQL to relational algebra
>
>
> Key: CALCITE-2787
> URL: https://issues.apache.org/jira/browse/CALCITE-2787
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.18.0
>Reporter: Hongze Zhang
>Assignee: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.19.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> SQL:
>
> {code:sql}
> WITH tab(x) AS (VALUES 1, 2, 1, CAST(NULL AS INTEGER))
> SELECT JSON_ARRAYAGG(x), JSON_ARRAYAGG(x NULL ON NULl) FROM tab
> {code}
> Produces:
> {code}
> EXPR$0 |EXPR$1 |
> ||
> [1,2,1] |[1,2,1] |
> {code}
> Should be:
> {code}
> EXPR$0 |EXPR$1 |
> ||
> [1,2,1] |[1,2,1,null] |
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-2787) Json aggregate calls with different null clause get incorrectly merged during converting from SQL to relational algebra
[
https://issues.apache.org/jira/browse/CALCITE-2787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang resolved CALCITE-2787.
---
Resolution: Fixed
Fix Version/s: 1.19.0
Fixed in
[5ada462e6f792deee7185ad2df8ec58380061d59|https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=5ada462e6f792deee7185ad2df8ec58380061d59].
> Json aggregate calls with different null clause get incorrectly merged
> during converting from SQL to relational algebra
>
>
> Key: CALCITE-2787
> URL: https://issues.apache.org/jira/browse/CALCITE-2787
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.18.0
>Reporter: Hongze Zhang
>Assignee: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.19.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> SQL:
>
> {code:sql}
> WITH tab(x) AS (VALUES 1, 2, 1, CAST(NULL AS INTEGER))
> SELECT JSON_ARRAYAGG(x), JSON_ARRAYAGG(x NULL ON NULl) FROM tab
> {code}
> Produces:
> {code}
> EXPR$0 |EXPR$1 |
> ||
> [1,2,1] |[1,2,1] |
> {code}
> Should be:
> {code}
> EXPR$0 |EXPR$1 |
> ||
> [1,2,1] |[1,2,1,null] |
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2879) Improve filter condition in Join
[
https://issues.apache.org/jira/browse/CALCITE-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-2879:
Labels: pull-request-available (was: )
> Improve filter condition in Join
>
>
> Key: CALCITE-2879
> URL: https://issues.apache.org/jira/browse/CALCITE-2879
> Project: Calcite
> Issue Type: Improvement
>Reporter: yuqi
>Priority: Major
> Labels: pull-request-available
>
> Currently, filter condition in join have not been optimized very well, let's
> take a simple example
> {code:sql}
> select a.id, b.name from Ta a inner join Tb b on a.id = b.id and a.id < 5;
> {code}
> now, only a.id < 5 can push down, however, as for the sql above,
> we can infer a.id < 5 and b.id < 5 and both of them can push down.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2703) Reduce code generation and class loading overhead when executing queries in the EnumerableConvention
[ https://issues.apache.org/jira/browse/CALCITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779291#comment-16779291 ] Stamatis Zampetakis commented on CALCITE-2703: -- Below, I outline a few alternative names (along with a short description) for property "calcite.bindable.cache.maxSize". Among them, I still prefer the initial one but if you (mostly referring to [~vladimirsitnikov]) have a different opinion let me know and I will use that one. +Reminder+ The interface defines Bindable as a "Statement that can be bound to a DataContext and then executed". +Alternatives+ * *calcite.bindable.cache.maxSize*: The maximum size of the cache used for storing Bindable objects, instantiated via dynamically generated Java classes. * *calcite.codegen.plan.cache.maxSize*: The maximum size of the cache used for storing execution plans, instantiated via dynamically generated Java classes. * *calcite.executable.cache.maxSize*, *calcite.runtime.plan.cache.maxSize*, *calcite.execution.plan.cache.maxSize*: The maximum size of the cache used for storing ready to execute query plan instances. * *calcite.statement.cache.maxSize*: The maximum size of the cache that is used for storing ready to execute statements. * *calcite.interpreter.plan.cache.maxSize* * *calcite.interpreter.query.cache.maxSize* FYI: I plan to merge the PR tomorrow. > Reduce code generation and class loading overhead when executing queries in > the EnumerableConvention > > > Key: CALCITE-2703 > URL: https://issues.apache.org/jira/browse/CALCITE-2703 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Labels: performance, pull-request-available > Time Spent: 3h > Remaining Estimate: 0h > > The queries using Calcite's EnumerableConvention always end-up generating new > java classes at runtime (using Janino) that are then instantiated using > reflection. This combination of class generation and class loading introduces > a big overhead in query response time. > A quick profiling on our Company's internal test suite consisting in 4000 > tests with roughly 43 SQL queries passing through Calcite we observed > that a big amount of time is spend on code generation and class loading > making the EnumerableInterpretable#toBindable method a performance > bottleneck. > Among the 43 SQL queries there are many duplicates which are going to > lead to the generation of exactly the same code Java. Introducing, a small > cache at the level of EnumerableInterpretable class could avoid generating > and loading the same code over and over again. > A simple implementation based on Guava improved the overall execution time of > the afforementioned test suite by more than 50%. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2879) Improve filter condition in Join
yuqi created CALCITE-2879:
-
Summary: Improve filter condition in Join
Key: CALCITE-2879
URL: https://issues.apache.org/jira/browse/CALCITE-2879
Project: Calcite
Issue Type: Improvement
Reporter: yuqi
Currently, filter condition in join have not been optimized very well, let's
take a simple example
{code:sql}
select a.id, b.name from Ta a inner join Tb b on a.id = b.id and a.id < 5;
{code}
now, only a.id < 5 can push down, however, as for the sql above,
we can infer a.id < 5 and b.id < 5 and both of them can push down.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2864) Add the JSON_DEPTH function
[
https://issues.apache.org/jira/browse/CALCITE-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779297#comment-16779297
]
Michael Mior commented on CALCITE-2864:
---
Fixed in
[cfc6a4d|https://github.com/apache/calcite/commit/cfc6a4df50b49c697a2a4aba36279946140d86cc].
> Add the JSON_DEPTH function
> ---
>
> Key: CALCITE-2864
> URL: https://issues.apache.org/jira/browse/CALCITE-2864
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Returns the maximum depth of a JSON document. Returns {{NULL}} if the
> argument is {{NULL}}. An error occurs if the argument is not a valid JSON
> document.
> An empty array, empty object, or scalar value has depth 1. A nonempty array
> containing only elements of depth 1 or nonempty object containing only member
> values of depth 1 has depth 2. Otherwise, a JSON document has depth greater
> than 2.
>
> Example Sql:
> SELECT JSON_DEPTH(v) AS c1
> ,JSON_DEPTH(JSON_VALUE(v, 'lax $.b' ERROR ON ERROR)) AS c2
> ,JSON_DEPTH(JSON_VALUE(v, 'strict $.a[0]' ERROR ON ERROR)) AS c3
> ,JSON_DEPTH(JSON_VALUE(v, 'strict $.a[1]' ERROR ON ERROR)) AS c4
> FROM (VALUES ('
> {"a": [10, true],"b": "[10, true]"}
> ')) AS t(v)
> limit 10;
> Result:
> c1 c2 c3 c4
> == == == ==
> 3 2 1 1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-2864) Add the JSON_DEPTH function
[
https://issues.apache.org/jira/browse/CALCITE-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior resolved CALCITE-2864.
---
Resolution: Fixed
Fix Version/s: 1.19.0
> Add the JSON_DEPTH function
> ---
>
> Key: CALCITE-2864
> URL: https://issues.apache.org/jira/browse/CALCITE-2864
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.19.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Returns the maximum depth of a JSON document. Returns {{NULL}} if the
> argument is {{NULL}}. An error occurs if the argument is not a valid JSON
> document.
> An empty array, empty object, or scalar value has depth 1. A nonempty array
> containing only elements of depth 1 or nonempty object containing only member
> values of depth 1 has depth 2. Otherwise, a JSON document has depth greater
> than 2.
>
> Example Sql:
> SELECT JSON_DEPTH(v) AS c1
> ,JSON_DEPTH(JSON_VALUE(v, 'lax $.b' ERROR ON ERROR)) AS c2
> ,JSON_DEPTH(JSON_VALUE(v, 'strict $.a[0]' ERROR ON ERROR)) AS c3
> ,JSON_DEPTH(JSON_VALUE(v, 'strict $.a[1]' ERROR ON ERROR)) AS c4
> FROM (VALUES ('
> {"a": [10, true],"b": "[10, true]"}
> ')) AS t(v)
> limit 10;
> Result:
> c1 c2 c3 c4
> == == == ==
> 3 2 1 1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CALCITE-2703) Reduce code generation and class loading overhead when executing queries in the EnumerableConvention
[ https://issues.apache.org/jira/browse/CALCITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis reassigned CALCITE-2703: Assignee: Stamatis Zampetakis > Reduce code generation and class loading overhead when executing queries in > the EnumerableConvention > > > Key: CALCITE-2703 > URL: https://issues.apache.org/jira/browse/CALCITE-2703 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.17.0 >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Labels: performance, pull-request-available > Time Spent: 3h > Remaining Estimate: 0h > > The queries using Calcite's EnumerableConvention always end-up generating new > java classes at runtime (using Janino) that are then instantiated using > reflection. This combination of class generation and class loading introduces > a big overhead in query response time. > A quick profiling on our Company's internal test suite consisting in 4000 > tests with roughly 43 SQL queries passing through Calcite we observed > that a big amount of time is spend on code generation and class loading > making the EnumerableInterpretable#toBindable method a performance > bottleneck. > Among the 43 SQL queries there are many duplicates which are going to > lead to the generation of exactly the same code Java. Introducing, a small > cache at the level of EnumerableInterpretable class could avoid generating > and loading the same code over and over again. > A simple implementation based on Guava improved the overall execution time of > the afforementioned test suite by more than 50%. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2859) Centralize Calcite system properties
[
https://issues.apache.org/jira/browse/CALCITE-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779142#comment-16779142
]
Stamatis Zampetakis commented on CALCITE-2859:
--
{quote}Regarding SaffronProperties. Can you deprecate it and add its 6
properties allowInfiniteCostConverters, defaultCharset, defaultCollation,
defaultCollationStrength, metadataHandlerCacheMaximumSize into
CalciteSystemProperty. So, no code will be using SaffronProperties anymore.
Keep the properties in the "saffron." namespace for now, but you can add a
"calcite." alias if it's not too hard.
{quote}
I did what [~julianhyde] suggested and updated the PR. If nobody objects I will
merge it tomorrow.
> Centralize Calcite system properties
>
>
> Key: CALCITE-2859
> URL: https://issues.apache.org/jira/browse/CALCITE-2859
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.18.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 1.19.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently there are various system (jvm) properties exploited by Calcite
> which are distributed all over the codebase. System properties are part of
> the public API so they should be easily accessible and well documented.
> The goal is to centralize all system properties with the "calcite" prefix
> under a common class/interface/enum.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779056#comment-16779056 ] Julian Hyde commented on CALCITE-2846: -- There a couple of ways you could approach it. You could have pre-built operator tables for standard, oracle, mysql, and chain them together. Or you could use a builder that creates a new operator table containing the union of the operators. Both approaches would work. Pick whichever you prefer. It's OK to use references to operators (e.g. SqlStdOperatorTable.EQUALS) if they are standard and guaranteed to be available. Referencing operator instances from other operator tables might cause problems; suppose, for example, Oracle and MySQL both have an NVL operator but with different semantics. So, for dialect-specific operators I'd recommend looking them up by name. > Document Oracle-specific functions, such as NVL and LTRIM, in the SQL > reference > --- > > Key: CALCITE-2846 > URL: https://issues.apache.org/jira/browse/CALCITE-2846 > Project: Calcite > Issue Type: Improvement > Components: site >Reporter: Julian Hyde >Assignee: Hongze Zhang >Priority: Major > Labels: documentation > > Document Oracle-specific functions (DECODE, NVL, LTRIM, RTRIM, SUBSTR, > GREATEST, LEAST) in the [SQL > reference|https://calcite.apache.org/docs/reference.html]. > Same goes for MySQL-specific functions (e.g. JSON_TYPE). > I don't think we should have separate lists of Oracle-specific functions and > MySQL-specific functions. Because quite a few functions appear in more than > one place. Better, I think, to have a concise annotation against each > function which tables it occurs in. > The current list of tables is standard, oracle, spatial, mysql. Perhaps also > indicate whether a function is an extension to the SQL standard but still > occurs in Calcite's default table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
