[jira] [Commented] (CALCITE-1930) AggregateExpandDistinctAggregatesRule does not expand aggregates properly
[
https://issues.apache.org/jira/browse/CALCITE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16117594#comment-16117594
]
Julian Hyde commented on CALCITE-1930:
--
Thanks for finding and fixing this. A few comments:
* How crucial is the assumption that there's only one argument? Could we drop
it? Is it a new assumption, or did it already exist in the previous code? The
standard aggregate functions happen to have one argument, but real ones may
have many. Calcite has {{COUNT(x, y, z)}} as a built-in. So it would be really
useful if we dropped that assumption.
* Can you please add some tests to agg.iq? Sometimes we don't notice that rule
are producing the wrong relational algebra but you can't argue if the results
are wrong.
> AggregateExpandDistinctAggregatesRule does not expand aggregates properly
> -
>
> Key: CALCITE-1930
> URL: https://issues.apache.org/jira/browse/CALCITE-1930
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> A query with two aggregate calls, sum(comm) and min(comm), it produces an
> incorrect plan. The main problem is that it fails to index the input of
> sum(comm) and min(comm) properly. This seems to only happen in the special
> case where there is only one distinct aggregate call.
> {code}
> SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY
> deptno
> {code}
> AggregateExpandDistinctAggregatesRule produces the following plan in this
> case.
> {code}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)],
> EXPR$3=[SUM($1)])
> LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
> LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> In the above plan, the top LogicalAggregate EXPR$1=[SUM($3]] is incorrect, it
> should be SUM($2).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-1911) Support WITHIN clause in MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1911:
-
Summary: Support WITHIN clause in MATCH_RECOGNIZE (was: Support within
clause in MATCH_RECOGNIZE)
> Support WITHIN clause in MATCH_RECOGNIZE
>
>
> Key: CALCITE-1911
> URL: https://issues.apache.org/jira/browse/CALCITE-1911
> Project: Calcite
> Issue Type: Bug
>Reporter: Dian Fu
>Assignee: Julian Hyde
> Labels: match
>
> Window is an important feature for pattern detection, it defines the time
> duration for the events to match a pattern. Here is an example from
> [doc|https://docs.oracle.com/middleware/1213/eventprocessing/cql-reference/GUID-34D4968E-C55A-4BC7-B1CE-C84B202217BD.htm#CQLLR2119]:
> {code}
> SELECT T.Ac2, T.Bc2, T.Cc2
> FROM S
> MATCH_RECOGNIZE(
> MEASURES A.c2 as Ac2, B.c2 as Bc2, C.c2 as Cc2
> PATTERN (A (B+ | C)) within 3000 milliseconds
> DEFINE
> A as A.c1=10 or A.c1=25,
> B as B.c1=20 or B.c1=15 or B.c1=25,
> C as C.c1=15
> ) as T
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1911) Support within clause in MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16117548#comment-16117548
]
Julian Hyde commented on CALCITE-1911:
--
A few review comments:
* Add comments in Match etc. that interval can be null. Not-null is usually
assumed.
* Interval 0 is ok, right? So the message should say "Interval must be
non-negative".
* I don't think you need SqlIntervalQualifier.CONV.
org.apache.calcite.avatica.util.TimeUnit.multiplier is probably sufficient.
* In Match.explainTerms, if should ignore null interval, not print "interval:
null".
* I am surprised that you needed to add so much code for intervals in
SqlParserUtil, and indeed in reference.md. Were you not able to re-use existing
interval literal support?
* As I said earlier, we need a way to specify ordering. Maybe there is a
rowtime column on streams. But this clause also needs to work on tables, which
definitely don't have a rowtime column.
> Support within clause in MATCH_RECOGNIZE
>
>
> Key: CALCITE-1911
> URL: https://issues.apache.org/jira/browse/CALCITE-1911
> Project: Calcite
> Issue Type: Bug
>Reporter: Dian Fu
>Assignee: Julian Hyde
> Labels: match
>
> Window is an important feature for pattern detection, it defines the time
> duration for the events to match a pattern. Here is an example from
> [doc|https://docs.oracle.com/middleware/1213/eventprocessing/cql-reference/GUID-34D4968E-C55A-4BC7-B1CE-C84B202217BD.htm#CQLLR2119]:
> {code}
> SELECT T.Ac2, T.Bc2, T.Cc2
> FROM S
> MATCH_RECOGNIZE(
> MEASURES A.c2 as Ac2, B.c2 as Bc2, C.c2 as Cc2
> PATTERN (A (B+ | C)) within 3000 milliseconds
> DEFINE
> A as A.c1=10 or A.c1=25,
> B as B.c1=20 or B.c1=15 or B.c1=25,
> C as C.c1=15
> ) as T
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1931) rank/ntile/etc. functions should not always return INTEGER
[
https://issues.apache.org/jira/browse/CALCITE-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16117488#comment-16117488
]
Julian Hyde commented on CALCITE-1931:
--
What does the SQL standard say about these functions' return types?
Are these new return types completely un-controversial? If not, should we let
people specify a policy, as we did in CALCITE-845?
The extra arg to {{SqlRankFunction}}'s constructor looks like a breaking
change. Leave the current constructor, marked deprecated.
> rank/ntile/etc. functions should not always return INTEGER
> --
>
> Key: CALCITE-1931
> URL: https://issues.apache.org/jira/browse/CALCITE-1931
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> For example, rank() and percent_rank() both return INTEGER. For rank(), it
> would be better to return BIGINT; for percent_rank(), we should actually
> return double or float since it is a percent value. There are other rank
> functions that should return floating number instead of integer.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1932) Project.getPermutation() should return null if a column is repeated
[ https://issues.apache.org/jira/browse/CALCITE-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16117470#comment-16117470 ] Julian Hyde commented on CALCITE-1932: -- Reviewing and testing now. > Project.getPermutation() should return null if a column is repeated > --- > > Key: CALCITE-1932 > URL: https://issues.apache.org/jira/browse/CALCITE-1932 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > Project.getPermutation() returns true when the project is referencing [$1, > $1]. If a column repeats, it should not be considered a permutation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1932) Project.getPermutation() should return null if a column is repeated
[ https://issues.apache.org/jira/browse/CALCITE-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16117384#comment-16117384 ] MinJi Kim commented on CALCITE-1932: Thank you for reviewing this PR! Thanks! -Minji https://github.com/apache/calcite/pull/512 > Project.getPermutation() should return null if a column is repeated > --- > > Key: CALCITE-1932 > URL: https://issues.apache.org/jira/browse/CALCITE-1932 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > Project.getPermutation() returns true when the project is referencing [$1, > $1]. If a column repeats, it should not be considered a permutation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1932) Project.getPermutation() should return null if a column is repeated
MinJi Kim created CALCITE-1932: -- Summary: Project.getPermutation() should return null if a column is repeated Key: CALCITE-1932 URL: https://issues.apache.org/jira/browse/CALCITE-1932 Project: Calcite Issue Type: Bug Components: core Reporter: MinJi Kim Assignee: Julian Hyde Project.getPermutation() returns true when the project is referencing [$1, $1]. If a column repeats, it should not be considered a permutation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1931) rank/ntile/etc. functions should not always return INTEGER
[ https://issues.apache.org/jira/browse/CALCITE-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16117196#comment-16117196 ] MinJi Kim commented on CALCITE-1931: Thanks again for reviewing this! https://github.com/apache/calcite/pull/511 > rank/ntile/etc. functions should not always return INTEGER > -- > > Key: CALCITE-1931 > URL: https://issues.apache.org/jira/browse/CALCITE-1931 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > For example, rank() and percent_rank() both return INTEGER. For rank(), it > would be better to return BIGINT; for percent_rank(), we should actually > return double or float since it is a percent value. There are other rank > functions that should return floating number instead of integer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16117182#comment-16117182 ] Josh Elser commented on CALCITE-1240: - The canonical ASF repo is live at https://git-wip-us.apache.org/repos/asf?p=calcite-avatica-go.git The Github mirror is still in the process of being created, but should show up [here|https://github.com/apache?utf8=%E2%9C%93=calcite==] eventually > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1931) rank/ntile/etc. functions should not always return INTEGER
MinJi Kim created CALCITE-1931: -- Summary: rank/ntile/etc. functions should not always return INTEGER Key: CALCITE-1931 URL: https://issues.apache.org/jira/browse/CALCITE-1931 Project: Calcite Issue Type: Bug Components: core Reporter: MinJi Kim Assignee: Julian Hyde For example, rank() and percent_rank() both return INTEGER. For rank(), it would be better to return BIGINT; for percent_rank(), we should actually return double or float since it is a percent value. There are other rank functions that should return floating number instead of integer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1930) AggregateExpandDistinctAggregatesRule does not expand aggregates properly
[
https://issues.apache.org/jira/browse/CALCITE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16117052#comment-16117052
]
MinJi Kim commented on CALCITE-1930:
Here is an initial fix for this issue that I noticed for converting a single
distinct aggregate call. Please let me know if you have any comments or
feedback. Thanks!
https://github.com/apache/calcite/pull/510
> AggregateExpandDistinctAggregatesRule does not expand aggregates properly
> -
>
> Key: CALCITE-1930
> URL: https://issues.apache.org/jira/browse/CALCITE-1930
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> A query with two aggregate calls, sum(comm) and min(comm), it produces an
> incorrect plan. The main problem is that it fails to index the input of
> sum(comm) and min(comm) properly. This seems to only happen in the special
> case where there is only one distinct aggregate call.
> {code}
> SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY
> deptno
> {code}
> AggregateExpandDistinctAggregatesRule produces the following plan in this
> case.
> {code}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)],
> EXPR$3=[SUM($1)])
> LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
> LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> In the above plan, the top LogicalAggregate EXPR$1=[SUM($3]] is incorrect, it
> should be SUM($2).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-1930) AggregateExpandDistinctAggregatesRule does not expand aggregates properly
[
https://issues.apache.org/jira/browse/CALCITE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
MinJi Kim updated CALCITE-1930:
---
Description:
A query with two aggregate calls, sum(comm) and min(comm), it produces an
incorrect plan. The main problem is that it fails to index the input of
sum(comm) and min(comm) properly. This seems to only happen in the special
case where there is only one distinct aggregate call.
{code}
SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY deptno
{code}
AggregateExpandDistinctAggregatesRule produces the following plan in this case.
{code}
LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)],
EXPR$3=[SUM($1)])
LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{code}
In the above plan, the top LogicalAggregate EXPR$1=[SUM($3]] is incorrect, it
should be SUM($2).
was:
A query with two aggregate calls, sum(comm) and min(comm), it produces an
incorrect plan. The main problem is that it fails to index the input of
sum(comm) and min(comm) properly. This seems to only happen in the special
case where there is only one distinct aggregate call.
{code}
SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY deptno
{code}
AggregateExpandDistinctAggregatesRule produces the following plan in this case.
{code}
LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)],
EXPR$3=[SUM($1)])
LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{code}
> AggregateExpandDistinctAggregatesRule does not expand aggregates properly
> -
>
> Key: CALCITE-1930
> URL: https://issues.apache.org/jira/browse/CALCITE-1930
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> A query with two aggregate calls, sum(comm) and min(comm), it produces an
> incorrect plan. The main problem is that it fails to index the input of
> sum(comm) and min(comm) properly. This seems to only happen in the special
> case where there is only one distinct aggregate call.
> {code}
> SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY
> deptno
> {code}
> AggregateExpandDistinctAggregatesRule produces the following plan in this
> case.
> {code}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)],
> EXPR$3=[SUM($1)])
> LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
> LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> In the above plan, the top LogicalAggregate EXPR$1=[SUM($3]] is incorrect, it
> should be SUM($2).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-1930) AggregateExpandDistinctAggregatesRule does not expand aggregates properly
MinJi Kim created CALCITE-1930:
--
Summary: AggregateExpandDistinctAggregatesRule does not expand
aggregates properly
Key: CALCITE-1930
URL: https://issues.apache.org/jira/browse/CALCITE-1930
Project: Calcite
Issue Type: Bug
Components: core
Reporter: MinJi Kim
Assignee: Julian Hyde
A query with two aggregate calls, sum(comm) and min(comm), it produces an
incorrect plan. The main problem is that it fails to index the input of
sum(comm) and min(comm) properly. This seems to only happen in the special
case where there is only one distinct aggregate call.
{code}
SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY deptno
{code}
AggregateExpandDistinctAggregatesRule produces the following plan in this case.
{code}
LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)],
EXPR$3=[SUM($1)])
LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1787) thetaSketch Support for Druid Adapter
[
https://issues.apache.org/jira/browse/CALCITE-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116889#comment-16116889
]
Zain Humayun commented on CALCITE-1787:
---
[~julianhyde], [~bslim], or[~jcamachorodriguez] can you please review when you
get time? Thanks :)
> thetaSketch Support for Druid Adapter
> -
>
> Key: CALCITE-1787
> URL: https://issues.apache.org/jira/browse/CALCITE-1787
> Project: Calcite
> Issue Type: New Feature
> Components: druid
>Affects Versions: 1.12.0
>Reporter: Zain Humayun
>Assignee: Zain Humayun
>
> Currently, the Druid adapter does not support the
> [thetaSketch|http://druid.io/docs/latest/development/extensions-core/datasketches-aggregators.html]
> aggregate type, which is used to measure the cardinality of a column
> quickly. Many Druid instances support theta sketches, so I think it would be
> a nice feature to have.
> I've been looking at the Druid adapter, and propose we add a new DruidType
> called {{thetaSketch}} and then add logic in the {{getJsonAggregation}}
> method in class {{DruidQuery}} to generate the {{thetaSketch}} aggregate.
> This will require accessing information about the columns (what data type
> they are) so that the thetaSketch aggregate is only produced if the column's
> type is {{thetaSketch}}.
> Also, I've noticed that a {{hyperUnique}} DruidType is currently defined, but
> a {{hyperUnique}} aggregate is never produced. Since both are approximate
> aggregators, I could also couple in the logic for {{hyperUnique}}.
> I'd love to hear your thoughts on my approach, and any suggestions you have
> for this feature.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1925) JaninoRelMetadataProvider to cache null value
[ https://issues.apache.org/jira/browse/CALCITE-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116887#comment-16116887 ] Julian Hyde commented on CALCITE-1925: -- I agree, a test is hard in this case. We can skip. Reviewing and testing now. > JaninoRelMetadataProvider to cache null value > - > > Key: CALCITE-1925 > URL: https://issues.apache.org/jira/browse/CALCITE-1925 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.13.0 >Reporter: Ted Xu >Assignee: Julian Hyde > > JaninoRelMetadataProvider should cache null value to improve performance. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116835#comment-16116835 ] Julian Hyde commented on CALCITE-1240: -- Sorry, I didn't actually check. I have limited network bandwidth. Josh, Please create it. Francis, Up to you whether you push the history or just the latest. Either is fine. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116813#comment-16116813 ] Josh Elser commented on CALCITE-1240: - I'm not seeing it either. Maybe INFRA just meant that they fixed the reporeq tool and didn't actually create the repo for you, [~julianhyde]? I can create it too -- I just don't want to cause a race-condition between us :) > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1929) Deprecate class RelDataTypeFactory.FieldInfoBuilder
Julian Hyde created CALCITE-1929:
Summary: Deprecate class RelDataTypeFactory.FieldInfoBuilder
Key: CALCITE-1929
URL: https://issues.apache.org/jira/browse/CALCITE-1929
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde
Since interface {{RelDataTypeFactory.FieldInfo}} is deprecated, and
{{RelDataTypeFactory.FieldInfoBuilder}} implements it, we should also deprecate
{{FieldInfoBuilder}}.
We will create a new class {{RelDataTypeFactory.Builder}} that does the same as
{{FieldInfoBuilder}} without implementing the {{FieldInfo}} interface.
For backwards compatibility, {{RelDataTypeFactory.builder()}} will continue to
return {{FieldInfoBuilder}} but we recommend that you assign the result to a
variable of type {{Builder}}. Thus you won't be using the deprecated class in
your code.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1911) Support within clause in MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116608#comment-16116608
]
Dian Fu commented on CALCITE-1911:
--
[~julianhyde] [~ransom], Have create a PR. Could you help to review? Thanks a
lot.
https://github.com/apache/calcite/pull/509
> Support within clause in MATCH_RECOGNIZE
>
>
> Key: CALCITE-1911
> URL: https://issues.apache.org/jira/browse/CALCITE-1911
> Project: Calcite
> Issue Type: Bug
>Reporter: Dian Fu
>Assignee: Julian Hyde
> Labels: match
>
> Window is an important feature for pattern detection, it defines the time
> duration for the events to match a pattern. Here is an example from
> [doc|https://docs.oracle.com/middleware/1213/eventprocessing/cql-reference/GUID-34D4968E-C55A-4BC7-B1CE-C84B202217BD.htm#CQLLR2119]:
> {code}
> SELECT T.Ac2, T.Bc2, T.Cc2
> FROM S
> MATCH_RECOGNIZE(
> MEASURES A.c2 as Ac2, B.c2 as Bc2, C.c2 as Cc2
> PATTERN (A (B+ | C)) within 3000 milliseconds
> DEFINE
> A as A.c1=10 or A.c1=25,
> B as B.c1=20 or B.c1=15 or B.c1=25,
> C as C.c1=15
> ) as T
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1925) JaninoRelMetadataProvider to cache null value
[ https://issues.apache.org/jira/browse/CALCITE-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116370#comment-16116370 ] Ted Xu commented on CALCITE-1925: - It's a bit hard to create a unit test. [~julianhyde] could you please have a look at my pull request? > JaninoRelMetadataProvider to cache null value > - > > Key: CALCITE-1925 > URL: https://issues.apache.org/jira/browse/CALCITE-1925 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.13.0 >Reporter: Ted Xu >Assignee: Julian Hyde > > JaninoRelMetadataProvider should cache null value to improve performance. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116311#comment-16116311 ] Francis Chuang commented on CALCITE-1240: - Also, I can't find the avatica-go repo in the Apache org on github. > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116173#comment-16116173 ] Francis Chuang commented on CALCITE-1240: - [~julianhyde]Should I push the whole commit history from the old repo, or just the latest commit (without the history)? > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1849) Support sub-queries (RexSubQuery) in RelToSqlConverter
[ https://issues.apache.org/jira/browse/CALCITE-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116128#comment-16116128 ] Zhiqiang He commented on CALCITE-1849: -- [~julianhyde] if expression is already changed to assert. please reivew it. thanks. > Support sub-queries (RexSubQuery) in RelToSqlConverter > -- > > Key: CALCITE-1849 > URL: https://issues.apache.org/jira/browse/CALCITE-1849 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.12.0 >Reporter: Zhiqiang He >Assignee: Zhiqiang He > > RelToSqlConverter does not currently support sub-queries (RexSubQuery), but > it should. > SqlToRelConverter, in the default configuration, converts sub-queries into > Join clause. But when SqlToRelConverter.Config.expand = false, it does not > convert them to Join. And that causes problems because RelToSqlConverter > cannot handle them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
