[jira] [Closed] (CALCITE-2258) Avatica Go - .travis.yml

2018-06-04 Thread Francis Chuang (JIRA)


 [ 
https://issues.apache.org/jira/browse/CALCITE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francis Chuang closed CALCITE-2258.
---

> Avatica Go - .travis.yml
> 
>
> Key: CALCITE-2258
> URL: https://issues.apache.org/jira/browse/CALCITE-2258
> Project: Calcite
>  Issue Type: Improvement
>  Components: avatica-go
>Reporter: Kevin Risden
>Assignee: Francis Chuang
>Priority: Major
>  Labels: test
> Fix For: avatica-go-3.0.0
>
>
> Adding .travis.yml to test avatica-go based on existing wercker.yml



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (CALCITE-1240) Avatica client written in Golang

2018-06-04 Thread Francis Chuang (JIRA)


 [ 
https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francis Chuang closed CALCITE-1240.
---
Assignee: Francis Chuang  (was: Julian Hyde)

> Avatica client written in Golang
> 
>
> Key: CALCITE-1240
> URL: https://issues.apache.org/jira/browse/CALCITE-1240
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica-go
>Reporter: Julian Hyde
>Assignee: Francis Chuang
>Priority: Major
> Fix For: avatica-go-3.0.0
>
>
> 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
(v7.6.3#76005)


[jira] [Updated] (CALCITE-2258) Avatica Go - .travis.yml

2018-06-04 Thread Francis Chuang (JIRA)


 [ 
https://issues.apache.org/jira/browse/CALCITE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francis Chuang updated CALCITE-2258:

Fix Version/s: avatica-go-3.0.0

> Avatica Go - .travis.yml
> 
>
> Key: CALCITE-2258
> URL: https://issues.apache.org/jira/browse/CALCITE-2258
> Project: Calcite
>  Issue Type: Improvement
>  Components: avatica-go
>Reporter: Kevin Risden
>Assignee: Francis Chuang
>Priority: Major
>  Labels: test
> Fix For: avatica-go-3.0.0
>
>
> Adding .travis.yml to test avatica-go based on existing wercker.yml



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (CALCITE-1938) First Apache release for Avatica Go

2018-06-04 Thread Francis Chuang (JIRA)


 [ 
https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francis Chuang updated CALCITE-1938:

Fix Version/s: avatica-go-3.0.0

> First Apache release for Avatica Go
> ---
>
> Key: CALCITE-1938
> URL: https://issues.apache.org/jira/browse/CALCITE-1938
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica-go
>Reporter: Julian Hyde
>Assignee: Francis Chuang
>Priority: Major
> Fix For: avatica-go-3.0.0
>
>
> Make a release for Avatica Go.
> Release number is TBD.
> This will be the first Apache release for Avatica Go, so expect more 
> diligence / issues than usual.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (CALCITE-1938) First Apache release for Avatica Go

2018-06-04 Thread Francis Chuang (JIRA)


 [ 
https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francis Chuang resolved CALCITE-1938.
-
Resolution: Fixed

> First Apache release for Avatica Go
> ---
>
> Key: CALCITE-1938
> URL: https://issues.apache.org/jira/browse/CALCITE-1938
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica-go
>Reporter: Julian Hyde
>Assignee: Francis Chuang
>Priority: Major
> Fix For: avatica-go-3.0.0
>
>
> Make a release for Avatica Go.
> Release number is TBD.
> This will be the first Apache release for Avatica Go, so expect more 
> diligence / issues than usual.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (CALCITE-1938) First Apache release for Avatica Go

2018-06-04 Thread Francis Chuang (JIRA)


 [ 
https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francis Chuang closed CALCITE-1938.
---

> First Apache release for Avatica Go
> ---
>
> Key: CALCITE-1938
> URL: https://issues.apache.org/jira/browse/CALCITE-1938
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica-go
>Reporter: Julian Hyde
>Assignee: Francis Chuang
>Priority: Major
> Fix For: avatica-go-3.0.0
>
>
> Make a release for Avatica Go.
> Release number is TBD.
> This will be the first Apache release for Avatica Go, so expect more 
> diligence / issues than usual.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (CALCITE-1937) Web site for Avatica Go

2018-06-04 Thread Francis Chuang (JIRA)


 [ 
https://issues.apache.org/jira/browse/CALCITE-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francis Chuang updated CALCITE-1937:

Fix Version/s: avatica-go-3.0.0

> Web site for Avatica Go
> ---
>
> Key: CALCITE-1937
> URL: https://issues.apache.org/jira/browse/CALCITE-1937
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica-go
>Reporter: Julian Hyde
>Assignee: Francis Chuang
>Priority: Major
> Fix For: avatica-1.12.0, avatica-go-3.0.0
>
>
> Create a web site for calcite-avatica-go.
> How about this:
> * At run time, the pages should appear under http://calcite.apache.org/avatica
> * The pages should be source-controlled under calcite-avatica-go/site, in 
> markdown format (same as calcite and avatica), and generated into svn using 
> similar trickery to calcite and avatica.
> * Reduce the amount of content in 
> https://github.com/apache/calcite-avatica-go/blob/master/README.md. The 
> "documentation" stuff should move to under http://calcite.apache.org/avatica. 
> So the page will be mainly a re-direct to the Apache home page. Similar to 
> https://github.com/apache/calcite-avatica/blob/master/README.md, in fact.
> * Add a go_history.md file.
> Should avatica-go appear on http://calcite.apache.org/avatica/downloads, or 
> should it have its own download page? I think it probably the former.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (CALCITE-2333) Stop releasing ZIPs

2018-06-04 Thread Francis Chuang (JIRA)


 [ 
https://issues.apache.org/jira/browse/CALCITE-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francis Chuang updated CALCITE-2333:

Fix Version/s: (was: 1.17.0)

> Stop releasing ZIPs
> ---
>
> Key: CALCITE-2333
> URL: https://issues.apache.org/jira/browse/CALCITE-2333
> Project: Calcite
>  Issue Type: Task
>  Components: avatica, avatica-go, core
>Reporter: Francis Chuang
>Assignee: Francis Chuang
>Priority: Trivial
> Fix For: avatica-1.12.0, 1.17.0
>
>
> There was some discussion on the mailing list regarding releasing our source 
> in just 1 format.
> See 
> [https://mail-archives.apache.org/mod_mbox/calcite-dev/201804.mbox/%3CD60019E6-FC62-4C24-B2F0-5278E51E5626%40apache.org%3E]
> There is some consensus around just releasing a tar.gz. I think this is a 
> good idea and is something we should aim for, for the Calcite 1.17 and 
> Avatica 1.12 releases.
> The following changes will be needed:
>  * Update build script for avatica-go.
>  * Update maven config for avatica.
>  * Update calcite config for calcite.
> We will need to update the website to deal the zip files not existing. My 
> proposal is that we edit the old release posts to include a `has_zip: true` 
> property. For the old releases, the website should render a link to the zip. 
> For the new releases, we do not need to do anything.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (CALCITE-2333) Stop releasing ZIPs

2018-06-04 Thread Francis Chuang (JIRA)


 [ 
https://issues.apache.org/jira/browse/CALCITE-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francis Chuang updated CALCITE-2333:

Fix Version/s: 1.17.0

> Stop releasing ZIPs
> ---
>
> Key: CALCITE-2333
> URL: https://issues.apache.org/jira/browse/CALCITE-2333
> Project: Calcite
>  Issue Type: Task
>  Components: avatica, avatica-go, core
>Reporter: Francis Chuang
>Assignee: Francis Chuang
>Priority: Trivial
> Fix For: avatica-1.12.0, 1.17.0
>
>
> There was some discussion on the mailing list regarding releasing our source 
> in just 1 format.
> See 
> [https://mail-archives.apache.org/mod_mbox/calcite-dev/201804.mbox/%3CD60019E6-FC62-4C24-B2F0-5278E51E5626%40apache.org%3E]
> There is some consensus around just releasing a tar.gz. I think this is a 
> good idea and is something we should aim for, for the Calcite 1.17 and 
> Avatica 1.12 releases.
> The following changes will be needed:
>  * Update build script for avatica-go.
>  * Update maven config for avatica.
>  * Update calcite config for calcite.
> We will need to update the website to deal the zip files not existing. My 
> proposal is that we edit the old release posts to include a `has_zip: true` 
> property. For the old releases, the website should render a link to the zip. 
> For the new releases, we do not need to do anything.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (CALCITE-1938) First Apache release for Avatica Go

2018-06-04 Thread Francis Chuang (JIRA)


 [ 
https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francis Chuang closed CALCITE-1938.
---

> First Apache release for Avatica Go
> ---
>
> Key: CALCITE-1938
> URL: https://issues.apache.org/jira/browse/CALCITE-1938
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica-go
>Reporter: Julian Hyde
>Assignee: Francis Chuang
>Priority: Major
>
> Make a release for Avatica Go.
> Release number is TBD.
> This will be the first Apache release for Avatica Go, so expect more 
> diligence / issues than usual.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CALCITE-2348) handling non-deterministic operator in rules

2018-06-04 Thread godfrey he (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16501251#comment-16501251
 ] 

godfrey he commented on CALCITE-2348:
-

Sorry I did not express clearly.

Yes, I totally agree with you. There are two examples that I am thinking of now 
for different scenarios:

1. case that the non-deterministic operator should not be pushed down:

 
{code:java}
// rand_substr is a non-deterministic udf
select ename, deptno from 
(select rand_substr(ename, 1, 3) as ename, deptno from emp) t 
where deptno > 10 and ename <> 'Tom';

before FilterProjectTransposeRule applied:
LogicalProject(ENAME=[$0], DEPTNO=[$1])
  LogicalFilter(condition=[AND(>($1, 10), <>($0, 'Tom'))])
LogicalProject(ENAME=[RAND_SUBSTR($1, 1, 3)], DEPTNO=[$7])
  LogicalTableScan(table=[[CATALOG, SALES, EMP]])

after FilterProjectTransposeRule applied:
LogicalProject(ENAME=[$0], DEPTNO=[$1])
  LogicalProject(ENAME=[RAND_SUBSTR($1, 1, 3)], DEPTNO=[$7])
LogicalFilter(condition=[AND(>($7, 10), <>(RAND_SUBSTR($1, 1, 3), 'Tom'))])
  LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{code}
The values of 'ename' should not contain 'Tom'. However after 
FilterProjectTransposeRule applied, 'Tom'  may be in the result.

 

2. case that the non-deterministic operator can be pushed down:
{code:java}
// rand_substr is a non-deterministic udf
select ename, deptno from 
(select ename, deptno from emp) t 
where deptno > 10 and rand_substr(ename, 1, 3) <> 'Tom';

before FilterProjectTransposeRule applied:
LogicalProject(ENAME=[$0], DEPTNO=[$1])
  LogicalFilter(condition=[AND(>($1, 10), <>($0, 'Tom'))])
LogicalProject(ENAME=[RAND_SUBSTR($1, 1, 3)], DEPTNO=[$7])
  LogicalTableScan(table=[[CATALOG, SALES, EMP]])

after FilterProjectTransposeRule applied:
LogicalProject(ENAME=[$0], DEPTNO=[$1])
  LogicalProject(ENAME=[$1], DEPTNO=[$7])
LogicalFilter(condition=[AND(<>(RAND_SUBSTR($1, 1, 3), 'Tom'), >($7, 10))])
  LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{code}
 

 

> 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
>Assignee: Julian Hyde
>Priority: Major
>
> 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] [Comment Edited] (CALCITE-1436) AggregateNode NPE for aggregators other than SUM/COUNT

2018-06-04 Thread Muhammad Gelbana (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500452#comment-16500452
 ] 

Muhammad Gelbana edited comment on CALCITE-1436 at 6/4/18 8:46 PM:
---

All tests ran fine. I created a Pull request: 
[https://github.com/apache/calcite/pull/719]


was (Author: mgelbana):
All tests ran find. I created a Pull request: 
[https://github.com/apache/calcite/pull/719]

> AggregateNode NPE for aggregators other than SUM/COUNT
> --
>
> Key: CALCITE-1436
> URL: https://issues.apache.org/jira/browse/CALCITE-1436
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Reporter: Gian Merlino
>Assignee: Julian Hyde
>Priority: Major
>
> AggregateNode.getAccumulator does this for any aggregation other than COUNT 
> or SUM:
>   final AggImpState agg = new AggImpState(0, call, false);
>   int stateSize = agg.state.size();
> This NPEs because "state" is null on freshly created AggImpState instances.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CALCITE-194) Array items in MongoDB adapter

2018-06-04 Thread Igor Kryvenko (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500827#comment-16500827
 ] 

Igor Kryvenko commented on CALCITE-194:
---

I have created a pull request with the fix: 
[https://github.com/apache/calcite/pull/720]. Could someone please take a look?

 

Thanks, Igor.

> 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
>
> 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] [Assigned] (CALCITE-194) Array items in MongoDB adapter

2018-06-04 Thread Igor Kryvenko (JIRA)


 [ 
https://issues.apache.org/jira/browse/CALCITE-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Kryvenko reassigned CALCITE-194:
-

Assignee: Igor Kryvenko

> 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
>
> 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] [Commented] (CALCITE-2345) add tests using Fongo to Mongo Adapter

2018-06-04 Thread Julian Hyde (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500667#comment-16500667
 ] 

Julian Hyde commented on CALCITE-2345:
--

bq. Are you OK if I copy zips.json to both 
elasticsearch[2,5]/src/test/resources and mongodb/src/test/resources ? Or 
should it be shared via core/src/test/resources (ie exporting test jar) ?

For now, do whichever is easiest for you. Which is probably putting a copy in 
each module's test/resources directory. After you have a PR working, then let's 
see if we can improve, e.g. move it into an external maven resource.

> add tests using Fongo to Mongo Adapter
> --
>
> Key: CALCITE-2345
> URL: https://issues.apache.org/jira/browse/CALCITE-2345
> Project: Calcite
>  Issue Type: Improvement
>Reporter: Andrei Sereda
>Assignee: Michael Mior
>Priority: Major
>
> Better test coverage for unit tests using 
> [Fongo|https://github.com/fakemongo/fongo] which is in-memory implementation 
> of Mongo API.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CALCITE-2345) add tests using Fongo to Mongo Adapter

2018-06-04 Thread Andrei Sereda (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500640#comment-16500640
 ] 

Andrei Sereda commented on CALCITE-2345:


{quote}Easiest thing to start with is to copy-paste zips.json from 
https://github.com/vlsi/calcite-test-dataset/tree/master/zips/src/main/resources/dataset
 into Calcite. Maybe we can convert that to a maven resource later on.{quote}
Are you OK if I copy {{zips.json}} to both 
{{elasticsearch[2,5]/src/test/resources}} and {{mongodb/src/test/resources}} ? 
Or should it be shared via {{core/src/test/resources}} (ie exporting test jar) 
? 

{quote}That said, I don't want to double the amount of test code that we 
have.{quote}
Agree. 

> add tests using Fongo to Mongo Adapter
> --
>
> Key: CALCITE-2345
> URL: https://issues.apache.org/jira/browse/CALCITE-2345
> Project: Calcite
>  Issue Type: Improvement
>Reporter: Andrei Sereda
>Assignee: Michael Mior
>Priority: Major
>
> Better test coverage for unit tests using 
> [Fongo|https://github.com/fakemongo/fongo] which is in-memory implementation 
> of Mongo API.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CALCITE-2345) add tests using Fongo to Mongo Adapter

2018-06-04 Thread Julian Hyde (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500608#comment-16500608
 ] 

Julian Hyde commented on CALCITE-2345:
--

bq. How can I get zips data in unit test (classpath) ? Should it be separate 
artifact (maven central?) or somewhere in test/resources ? 

Easiest thing to start with is to copy-paste zips.json from 
https://github.com/vlsi/calcite-test-dataset/tree/master/zips/src/main/resources/dataset
 into Calcite. Maybe we can convert that to a maven resource later on.

bq. Both issues have similar goals: execute AdapterIT tests using in-memory 
fakes in addition to existing integration tests.

Yes, I would like to have integration tests in addition to tests against a fake 
database.

That said, I don't want to double the amount of test code that we have. (We 
have more test code for the Mongo adapter than the Calcite community is able to 
maintain; for instance,  existing tests have broken over time.) I would like to 
keep the existing tests and allow them to be run in two different ways. Maybe 
move the existing tests that are in MongoAdapterIT into a base class?

> add tests using Fongo to Mongo Adapter
> --
>
> Key: CALCITE-2345
> URL: https://issues.apache.org/jira/browse/CALCITE-2345
> Project: Calcite
>  Issue Type: Improvement
>Reporter: Andrei Sereda
>Assignee: Michael Mior
>Priority: Major
>
> Better test coverage for unit tests using 
> [Fongo|https://github.com/fakemongo/fongo] which is in-memory implementation 
> of Mongo API.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (CALCITE-2348) handling non-deterministic operator in rules

2018-06-04 Thread Julian Hyde (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500589#comment-16500589
 ] 

Julian Hyde edited comment on CALCITE-2348 at 6/4/18 5:39 PM:
--

Not sure what you mean by "take care of". If it's not valid to push an operator 
down (because the operator is non-deterministic), the rules don't push it down. 
Doing nothing is the right thing to do.

Maybe there are some kinds of non-determinism where it would be OK to push an 
operator down. In which case, I'm happy to talk about other kinds of 
non-determinism.


was (Author: julianhyde):
Not sure what you mean by "take care of". If it's not valid to push an operator 
down (because the operator is non-deterministic), the rules don't push it down.

Maybe there are some kinds of non-determinism where it would be OK to push an 
operator down. In which case, I'm happy to talk about other kinds of 
non-determinism.

> 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
>Assignee: Julian Hyde
>Priority: Major
>
> 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] [Commented] (CALCITE-2348) handling non-deterministic operator in rules

2018-06-04 Thread Julian Hyde (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500589#comment-16500589
 ] 

Julian Hyde commented on CALCITE-2348:
--

Not sure what you mean by "take care of". If it's not valid to push an operator 
down (because the operator is non-deterministic), the rules don't push it down.

Maybe there are some kinds of non-determinism where it would be OK to push an 
operator down. In which case, I'm happy to talk about other kinds of 
non-determinism.

> 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
>Assignee: Julian Hyde
>Priority: Major
>
> 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] [Commented] (CALCITE-1436) AggregateNode NPE for aggregators other than SUM/COUNT

2018-06-04 Thread Muhammad Gelbana (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500452#comment-16500452
 ] 

Muhammad Gelbana commented on CALCITE-1436:
---

All tests ran find. I created a Pull request: 
[https://github.com/apache/calcite/pull/719]

> AggregateNode NPE for aggregators other than SUM/COUNT
> --
>
> Key: CALCITE-1436
> URL: https://issues.apache.org/jira/browse/CALCITE-1436
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Reporter: Gian Merlino
>Assignee: Julian Hyde
>Priority: Major
>
> AggregateNode.getAccumulator does this for any aggregation other than COUNT 
> or SUM:
>   final AggImpState agg = new AggImpState(0, call, false);
>   int stateSize = agg.state.size();
> This NPEs because "state" is null on freshly created AggImpState instances.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CALCITE-1436) AggregateNode NPE for aggregators other than SUM/COUNT

2018-06-04 Thread Muhammad Gelbana (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500330#comment-16500330
 ] 

Muhammad Gelbana commented on CALCITE-1436:
---

Has anyone created a test case for this ? I'm failing to write a test case that 
reproduces it.

> AggregateNode NPE for aggregators other than SUM/COUNT
> --
>
> Key: CALCITE-1436
> URL: https://issues.apache.org/jira/browse/CALCITE-1436
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Reporter: Gian Merlino
>Assignee: Julian Hyde
>Priority: Major
>
> AggregateNode.getAccumulator does this for any aggregation other than COUNT 
> or SUM:
>   final AggImpState agg = new AggImpState(0, call, false);
>   int stateSize = agg.state.size();
> This NPEs because "state" is null on freshly created AggImpState instances.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (CALCITE-2015) Planner generates incompatible plan

2018-06-04 Thread Pavel Gubin (JIRA)


[ 
https://issues.apache.org/jira/browse/CALCITE-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500244#comment-16500244
 ] 

Pavel Gubin commented on CALCITE-2015:
--

I investigated it a bit more. Seems the problem is caused by the fact that 
planner indefinitely generates more and more possible plans and then exits on 
give up condition. But at this stage JdbcToEnumerable conversion rules was not 
applied and the plan is essentially incompatible.

Current workaround for me is to exclude {{JoinCommuteRule}} and 
{{JoinPushThroughJoinRule}} to brake cyclicity. In this case planner applies 
all rules and exits successfully.

But in the end need to understand how to exit indefinite planning correctly.

> Planner generates incompatible plan
> ---
>
> Key: CALCITE-2015
> URL: https://issues.apache.org/jira/browse/CALCITE-2015
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.14.0
>Reporter: Pavel Gubin
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: Main.java
>
>
> Rel tree was build using RelBuilder on foodmart dataset:
> {code:java}
> RelNode rel = b.scan("foodmart", "sales_fact_1998")
> .scan("foodmart", "customer")
> .join(JoinRelType.INNER, "customer_id")
> .scan("foodmart", "store")
> .join(JoinRelType.INNER, "store_id")
> .filter(b.equals(b.field("coffee_bar"), b.literal(true)))
> .project(
> b.alias(b.field("lname"), "lastName"),
> b.alias(b.field("store_name"), "storeName"),
> b.alias(b.field("coffee_bar"), "coffeeBar"),
> b.alias(b.field("unit_sales"), "unitSales")
> )
> .aggregate(b.groupKey(b.field("lastName"), 
> b.field("storeName"),
> b.field("coffeeBar")), b.sum(false, "unitSales", 
> b.field("unitSales")))
> .build();
> {code}
> This tree is optimised to the following physical plan:
> {noformat}
> 22:03:26.388 [main] DEBUG org.apache.calcite.prepare.Prepare - Plan after 
> physical tweaks: EnumerableAggregate(group=[{1, 6, 7}], 
> unitSales=[$SUM0($4)]): rowcount = 337.5, cumulative cost = {4466.6875 rows, 
> 839.0 cpu, 0.0 io}, id = 11032
>   JdbcJoin(condition=[=($2, $0)], joinType=[inner]): rowcount = 3375.0, 
> cumulative cost = {4087.0 rows, 839.0 cpu, 0.0 io}, id = 11030
> JdbcProject(customer_id=[$0], lname=[$2]): rowcount = 100.0, cumulative 
> cost = {180.0 rows, 261.0 cpu, 0.0 io}, id = 11018
>   JdbcTableScan(table=[[foodmart, customer]]): rowcount = 100.0, 
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 1
> JdbcJoin(condition=[=($1, $3)], joinType=[inner]): rowcount = 225.0, 
> cumulative cost = {532.0 rows, 578.0 cpu, 0.0 io}, id = 11028
>   JdbcProject(customer_id=[$2], store_id=[$4], unit_sales=[$7]): rowcount 
> = 100.0, cumulative cost = {180.0 rows, 341.0 cpu, 0.0 io}, id = 11021
> JdbcTableScan(table=[[foodmart, sales_fact_1998]]): rowcount = 100.0, 
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 0
>   JdbcProject(store_id=[$0], store_name=[$3], coffee_bar=[$19]): rowcount 
> = 15.0, cumulative cost = {127.0 rows, 237.0 cpu, 0.0 io}, id = 11026
> JdbcFilter(condition=[=($19, true)]): rowcount = 15.0, cumulative 
> cost = {115.0 rows, 201.0 cpu, 0.0 io}, id = 11024
>   JdbcTableScan(table=[[foodmart, store]]): rowcount = 100.0, 
> cumulative cost = {100.0 rows, 101.0 cpu, 0.0 io}, id = 3
> {noformat}
> Which fails on execution:
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: java.sql.SQLException: 
> Error while preparing statement [null]
>   at 
> org.apache.calcite.jdbc.CalciteConnectionImpl$1.prepare(CalciteConnectionImpl.java:172)
>   at Main.main(Main.java:68)
> Caused by: java.sql.SQLException: Error while preparing statement [null]
>   at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
>   at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
>   at 
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement_(CalciteConnectionImpl.java:210)
>   at 
> org.apache.calcite.jdbc.CalciteConnectionImpl.access$100(CalciteConnectionImpl.java:89)
>   at 
> org.apache.calcite.jdbc.CalciteConnectionImpl$1.prepare(CalciteConnectionImpl.java:168)
>   ... 1 more
> Caused by: java.lang.ClassCastException: 
> org.apache.calcite.adapter.jdbc.JdbcRules$JdbcJoin cannot be cast to 
> org.apache.calcite.adapter.enumerable.EnumerableRel
>   at 
> org.apache.calcite.adapter.enumerable.EnumerableAggregate.implement(EnumerableAggregate.java:105)
>   at 
>