Re: calcite regress a07c742 origin/master jdk9 status: 1 "[CALCITE-1619] CAST is ignored by rules pushing operators into DruidQuery"

[Jesus Camacho Rodriguez]

Hi Julian,

I have seen your message right now. I saw that a commit for fixing this up went 
in already, thanks a lot for catching and fixing it!

--
Jesús


From:  Julian Hyde 
Date:  Wednesday, February 8, 2017 at 8:45 PM
To:  Jesus Camacho Rodriguez 
Cc:  "dev@calcite.apache.org" 
Subject:  Re: calcite regress a07c742 origin/master jdk9 status: 1 
"[CALCITE-1619] CAST is ignored by rules pushing operators into DruidQuery"

Jesus, I can check in a fix for this with some other PRs. Since it’s late for 
you, I assume you’re not working on it, but let me know if you are working on 
it. 

On Feb 8, 2017, at 11:54 AM, Julian Hyde  wrote:

Jesus, 

Your recent commit broke the build due to a javadoc error. It shows up on JDK 8 
and 9, not sure about 7. Please run “mvn site” under JDK 8 or 9 before 
committing.

Julian


Begin forwarded message:

Subject: calcite regress a07c742 origin/master jdk9 status: 1 "[CALCITE-1619] 
CAST is ignored by rules pushing operators into DruidQuery" 
Date: February 8, 2017 at 2:46:30 AM PST

[ERROR] 
/home/jhyde/regress/calcite/druid/src/test/java/org/apache/calcite/test/DruidAdapterIT.java:806:
 error: reference not found
[ERROR] /** As {@link #testFilterSortDesc} but with a filter that cannot be 
pushed
[ERROR] ^
[ERROR] 
[ERROR] Command line was: /usr/lib/jvm/jdk9/bin/javadoc @options @packages
[ERROR] 
[ERROR] Refer to the generated Javadoc files in 
'/home/jhyde/regress/calcite/target/site/testapidocs' dir.
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

status 1
Finished at Wed Feb 8 02:46:30 PST 2017
Subject: calcite regress a07c742 origin/master jdk9 status: 1 "[CALCITE-1619] 
CAST is ignored by rules pushing operators into DruidQuery" 

[jira] [Created] (CALCITE-1624) Inefficient plan for NOT IN correlated subqueries

[Vineet Garg (JIRA)]

Vineet Garg created CALCITE-1624:


 Summary: Inefficient plan for NOT IN correlated subqueries
 Key: CALCITE-1624
 URL: https://issues.apache.org/jira/browse/CALCITE-1624
 Project: Calcite
  Issue Type: Bug
  Components: core
Reporter: Vineet Garg
Assignee: Julian Hyde


I just noticed that {{NOT IN}} correlated subqueries produces an extra 
un-neccessary join after de-correlation (this is an addition to un-necessary 
joins reported in CALCITE-1494)

Query
{code:SQL}
select sal from emp
where empno NOT IN (
  select deptno from dept
  where emp.job = dept.name)
{code}

Plan after subquery remove rule:
{code}
LogicalProject(SAL=[$5])
  LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4], 
SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
LogicalFilter(condition=[NOT(CASE(=($9, 0), false, IS NOT NULL($12), true, 
<($10, $9), true, false))])
  LogicalCorrelate(correlation=[$cor0], joinType=[LEFT], 
requiredColumns=[{2}])
LogicalCorrelate(correlation=[$cor0], joinType=[LEFT], 
requiredColumns=[{2}])
  LogicalTableScan(table=[[CATALOG, SALES, EMP]])
  LogicalAggregate(group=[{}], c=[COUNT()], ck=[COUNT($0)])
LogicalProject(DEPTNO=[$0])
  LogicalFilter(condition=[=($cor0.JOB, $1)])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
LogicalFilter(condition=[=($cor0.EMPNO, $0)])
  LogicalAggregate(group=[{0, 1}])
LogicalProject(DEPTNO=[$0], i=[true])
  LogicalProject(DEPTNO=[$0])
LogicalFilter(condition=[=($cor0.JOB, $1)])
  LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}

Plan after de-correlation
{code}
LogicalProject(SAL=[$5])
  LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4], 
SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
LogicalFilter(condition=[NOT(CASE(=($10, 0), false, IS NOT NULL($14), true, 
<($11, $10), true, false))])
  LogicalJoin(condition=[AND(=($0, $15), =($2, $13))], joinType=[left])
LogicalJoin(condition=[=($2, $9)], joinType=[left])
  LogicalTableScan(table=[[CATALOG, SALES, EMP]])
  LogicalAggregate(group=[{0}], c=[COUNT()], ck=[COUNT($1)])
LogicalProject(JOB=[$1], DEPTNO=[$0])
  LogicalProject(DEPTNO=[$0], JOB=[$2])
LogicalJoin(condition=[=($2, $1)], joinType=[inner])
  LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
  LogicalAggregate(group=[{0}])
LogicalProject(JOB=[$2])
  LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalJoin(condition=[=($3, $0)], joinType=[inner]) // <== 
Un-necessary join
  LogicalProject(DEPTNO=[$0], JOB=[$1], $f2=[true])
LogicalAggregate(group=[{0, 1}])
  LogicalProject(DEPTNO=[$0], JOB=[$2], i=[$1])
LogicalProject(DEPTNO=[$0], i=[true], JOB=[$1])
  LogicalProject(DEPTNO=[$0], JOB=[$2])
LogicalJoin(condition=[=($2, $1)], joinType=[inner])
  LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
  LogicalAggregate(group=[{0}])
LogicalProject(JOB=[$2])
  LogicalTableScan(table=[[CATALOG, SALES, EMP]])
  LogicalAggregate(group=[{0}])
LogicalProject(EMPNO=[$0])
  LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{code}

As you can see in plan after de-correlation there is an un-necessary inner join.

This is not reproducible on CALCITE-1494's branch. But since this is a separate 
issue from CALCITE-1494 I decided to open a separate JIRA.
Feel free to mark is duplicate or close it if you think otherwise.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [DISCUSS] Patches

[Julian Hyde]

I agree with you that JIRA is better at managing back-ports than git is.

In my view, non-trivial commits — anything that fixes a user bug or feature — 
should have a JIRA case. Calcite seems to follow this policy — about 95% of 
commits have a corresponding JIRA case. The remainder are usually for cosmetic 
code changes, documentation and web site changes.

Julian

> On Feb 8, 2017, at 2:56 PM, Alan Gates  wrote:
> 
> I agree PRs are easy to work with for developers.  Here's the same question I 
> was trying to ask put a different way:
> 
> If a user discovers that feature X is broken, how easy it for him to find out 
> whether someone before him has found this bug and then figure out what 
> version of the software he needs to fix it.  Bug tracking systems are 
> optimized for answering these queries, and I don't think source control 
> systems are.
> 
> Maybe calcite is enough developer focussed that anyone searching for issues 
> will be comfortable skimming through the git log to figure it out, so maybe 
> my concerns are moot in this case.
> 
> Alan.
> 
>> On Feb 8, 2017, at 12:30 PM, Julian Hyde  wrote:
>> 
>> In principle it is hard to compute the delta of a pull request, but in 
>> practice it is easy. A well-formed pull request is a branch that is a small 
>> number of commits away from the master branch at the time, and the pull 
>> requests that we tend to accept are well-formed.
>> 
>> Since we don’t rewrite the master branch, you can easily apply the pull 
>> request using “git rebase”. Because git knows where where the pull request’s 
>> branch meets the master branch, it can do a better job than “patch” could.
>> 
>> Julian
>> 
>> 
>>> On Feb 8, 2017, at 12:21 PM, Alan Gates  wrote:
>>> 
>>> I agree that PRs are easier to manage than attaching patches to JIRA.  And 
>>> now days most contributors seem to prefer them as well.
>>> 
>>> One question I have is about traceability and findability.  It is very nice 
>>> for people to be able to come to JIRA and figure out if others have had the 
>>> same problem they have, and if so if and where it's fixed, and exactly 
>>> which commits they need to pick up if they want the fix.  Can all this be 
>>> achieved with just PRs?
>>> 
>>> If the answer is that PRs can't achieve that, I'd still vote for moving to 
>>> them.  But I would also suggest continuing to open JIRAs that point to the 
>>> PRs.
>>> 
>>> Alan.
>>> 
 On Feb 8, 2017, at 11:33 AM, Julian Hyde  wrote:
 
 Our current policy is that we accept patches attached to JIRA case and 
 pull requests to https://github.com/apache/calcite 
 . I would like to propose that we no 
 longer support patches.
 
 Why? I argue that it makes the process easier for the committer. The pull 
 request implicitly does “git add” and “git remove”, whereas when applying 
 a patch you have to remember to apply these. The pull request comes in a 
 branch, so if I modify the code as I am reviewing it, I can easily save 
 and restore my state. Also, a pull request is “valid” as a contribution, 
 from an IP standpoint, even when not accompanied by a JIRA case.
 
 Recently I went through 5 rounds of patches for a particular feature. I 
 couldn’t tell what had changed between one iteration of the patch and the 
 next (you can’t “diff" patches - you need to apply the patches to separate 
 git branches and diff the branches - yuck!). And I went through 3 test 
 cycles and 24 hours before I managed to “git add” all of the files. Yes, I 
 did “git status” and I missed the 2 new files among all of the “.orig” and 
 “.rej” files in my sandbox.
 
 In summary. I propose that we accept contributions only as pull requests 
 to https://github.com/apache/calcite . 
 If they are non-trivial they should be accompanied by a JIRA case. 
 Committers can propose changes any way they like, as long as they commit 
 the changes themselves, but if they want to make it easier for others to 
 review, they should use either a personal git branch or a pull request.
 
 Julian
 
>>> 
>> 
> 

Re: [DISCUSS] Patches

[Alan Gates]

I agree PRs are easy to work with for developers.  Here's the same question I 
was trying to ask put a different way:

If a user discovers that feature X is broken, how easy it for him to find out 
whether someone before him has found this bug and then figure out what version 
of the software he needs to fix it.  Bug tracking systems are optimized for 
answering these queries, and I don't think source control systems are.

Maybe calcite is enough developer focussed that anyone searching for issues 
will be comfortable skimming through the git log to figure it out, so maybe my 
concerns are moot in this case.

Alan.

> On Feb 8, 2017, at 12:30 PM, Julian Hyde  wrote:
> 
> In principle it is hard to compute the delta of a pull request, but in 
> practice it is easy. A well-formed pull request is a branch that is a small 
> number of commits away from the master branch at the time, and the pull 
> requests that we tend to accept are well-formed.
> 
> Since we don’t rewrite the master branch, you can easily apply the pull 
> request using “git rebase”. Because git knows where where the pull request’s 
> branch meets the master branch, it can do a better job than “patch” could.
> 
> Julian
> 
> 
>> On Feb 8, 2017, at 12:21 PM, Alan Gates  wrote:
>> 
>> I agree that PRs are easier to manage than attaching patches to JIRA.  And 
>> now days most contributors seem to prefer them as well.
>> 
>> One question I have is about traceability and findability.  It is very nice 
>> for people to be able to come to JIRA and figure out if others have had the 
>> same problem they have, and if so if and where it's fixed, and exactly which 
>> commits they need to pick up if they want the fix.  Can all this be achieved 
>> with just PRs?
>> 
>> If the answer is that PRs can't achieve that, I'd still vote for moving to 
>> them.  But I would also suggest continuing to open JIRAs that point to the 
>> PRs.
>> 
>> Alan.
>> 
>>> On Feb 8, 2017, at 11:33 AM, Julian Hyde  wrote:
>>> 
>>> Our current policy is that we accept patches attached to JIRA case and pull 
>>> requests to https://github.com/apache/calcite 
>>> . I would like to propose that we no 
>>> longer support patches.
>>> 
>>> Why? I argue that it makes the process easier for the committer. The pull 
>>> request implicitly does “git add” and “git remove”, whereas when applying a 
>>> patch you have to remember to apply these. The pull request comes in a 
>>> branch, so if I modify the code as I am reviewing it, I can easily save and 
>>> restore my state. Also, a pull request is “valid” as a contribution, from 
>>> an IP standpoint, even when not accompanied by a JIRA case.
>>> 
>>> Recently I went through 5 rounds of patches for a particular feature. I 
>>> couldn’t tell what had changed between one iteration of the patch and the 
>>> next (you can’t “diff" patches - you need to apply the patches to separate 
>>> git branches and diff the branches - yuck!). And I went through 3 test 
>>> cycles and 24 hours before I managed to “git add” all of the files. Yes, I 
>>> did “git status” and I missed the 2 new files among all of the “.orig” and 
>>> “.rej” files in my sandbox.
>>> 
>>> In summary. I propose that we accept contributions only as pull requests to 
>>> https://github.com/apache/calcite . If 
>>> they are non-trivial they should be accompanied by a JIRA case. Committers 
>>> can propose changes any way they like, as long as they commit the changes 
>>> themselves, but if they want to make it easier for others to review, they 
>>> should use either a personal git branch or a pull request.
>>> 
>>> Julian
>>> 
>> 
> 

[jira] [Created] (CALCITE-1623) Make sure the Calendar inside DATE, TIME and TIMESTAMP literals has timezone UTC

[Julian Hyde (JIRA)]

Julian Hyde created CALCITE-1623:


 Summary: Make sure the Calendar inside DATE, TIME and TIMESTAMP 
literals has timezone UTC
 Key: CALCITE-1623
 URL: https://issues.apache.org/jira/browse/CALCITE-1623
 Project: Calcite
  Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde


At query preparation time, Calcite uses a Calendar to hold the value of DATE, 
TIME, TIMESTAMP literals. It assumes that Calendar has a UTC (GMT) time zone. 
Bad things probably happen if it does not. We should check, and throw 
IllegalArgumentException if not.

(For the record, Calendar is not used at run time. Those values become int or 
long, or Integer or Long if nullable.)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: calcite regress a07c742 origin/master jdk9 status: 1 "[CALCITE-1619] CAST is ignored by rules pushing operators into DruidQuery"

[Julian Hyde]

Jesus, I can check in a fix for this with some other PRs. Since it’s late for 
you, I assume you’re not working on it, but let me know if you are working on 
it.

> On Feb 8, 2017, at 11:54 AM, Julian Hyde  wrote:
> 
> Jesus,
> 
> Your recent commit broke the build due to a javadoc error. It shows up on JDK 
> 8 and 9, not sure about 7. Please run “mvn site” under JDK 8 or 9 before 
> committing.
> 
> Julian
> 
> 
>> Begin forwarded message:
>> 
>> Subject: calcite regress a07c742 origin/master jdk9 status: 1 
>> "[CALCITE-1619] CAST is ignored by rules pushing operators into DruidQuery" 
>> Date: February 8, 2017 at 2:46:30 AM PST
>> 
>> [ERROR] 
>> /home/jhyde/regress/calcite/druid/src/test/java/org/apache/calcite/test/DruidAdapterIT.java:806:
>>  error: reference not found
>> [ERROR] /** As {@link #testFilterSortDesc} but with a filter that cannot be 
>> pushed
>> [ERROR] ^
>> [ERROR] 
>> [ERROR] Command line was: /usr/lib/jvm/jdk9/bin/javadoc @options @packages
>> [ERROR] 
>> [ERROR] Refer to the generated Javadoc files in 
>> '/home/jhyde/regress/calcite/target/site/testapidocs' dir.
>> [ERROR] -> [Help 1]
>> [ERROR] 
>> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
>> switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR] 
>> [ERROR] For more information about the errors and possible solutions, please 
>> read the following articles:
>> [ERROR] [Help 1] 
>> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException 
>> 
>> 
>> status 1
>> Finished at Wed Feb 8 02:46:30 PST 2017
>> Subject: calcite regress a07c742 origin/master jdk9 status: 1 
>> "[CALCITE-1619] CAST is ignored by rules pushing operators into DruidQuery" 
> 

Re: [DISCUSS] Patches

[Julian Hyde]

In principle it is hard to compute the delta of a pull request, but in practice 
it is easy. A well-formed pull request is a branch that is a small number of 
commits away from the master branch at the time, and the pull requests that we 
tend to accept are well-formed.

Since we don’t rewrite the master branch, you can easily apply the pull request 
using “git rebase”. Because git knows where where the pull request’s branch 
meets the master branch, it can do a better job than “patch” could.

Julian


> On Feb 8, 2017, at 12:21 PM, Alan Gates  wrote:
> 
> I agree that PRs are easier to manage than attaching patches to JIRA.  And 
> now days most contributors seem to prefer them as well.
> 
> One question I have is about traceability and findability.  It is very nice 
> for people to be able to come to JIRA and figure out if others have had the 
> same problem they have, and if so if and where it's fixed, and exactly which 
> commits they need to pick up if they want the fix.  Can all this be achieved 
> with just PRs?
> 
> If the answer is that PRs can't achieve that, I'd still vote for moving to 
> them.  But I would also suggest continuing to open JIRAs that point to the 
> PRs.
> 
> Alan.
> 
>> On Feb 8, 2017, at 11:33 AM, Julian Hyde  wrote:
>> 
>> Our current policy is that we accept patches attached to JIRA case and pull 
>> requests to https://github.com/apache/calcite 
>> . I would like to propose that we no 
>> longer support patches.
>> 
>> Why? I argue that it makes the process easier for the committer. The pull 
>> request implicitly does “git add” and “git remove”, whereas when applying a 
>> patch you have to remember to apply these. The pull request comes in a 
>> branch, so if I modify the code as I am reviewing it, I can easily save and 
>> restore my state. Also, a pull request is “valid” as a contribution, from an 
>> IP standpoint, even when not accompanied by a JIRA case.
>> 
>> Recently I went through 5 rounds of patches for a particular feature. I 
>> couldn’t tell what had changed between one iteration of the patch and the 
>> next (you can’t “diff" patches - you need to apply the patches to separate 
>> git branches and diff the branches - yuck!). And I went through 3 test 
>> cycles and 24 hours before I managed to “git add” all of the files. Yes, I 
>> did “git status” and I missed the 2 new files among all of the “.orig” and 
>> “.rej” files in my sandbox.
>> 
>> In summary. I propose that we accept contributions only as pull requests to 
>> https://github.com/apache/calcite . If 
>> they are non-trivial they should be accompanied by a JIRA case. Committers 
>> can propose changes any way they like, as long as they commit the changes 
>> themselves, but if they want to make it easier for others to review, they 
>> should use either a personal git branch or a pull request.
>> 
>> Julian
>> 
> 

Re: [DISCUSS] Patches

[Alan Gates]

I agree that PRs are easier to manage than attaching patches to JIRA.  And now 
days most contributors seem to prefer them as well.

One question I have is about traceability and findability.  It is very nice for 
people to be able to come to JIRA and figure out if others have had the same 
problem they have, and if so if and where it's fixed, and exactly which commits 
they need to pick up if they want the fix.  Can all this be achieved with just 
PRs?

If the answer is that PRs can't achieve that, I'd still vote for moving to 
them.  But I would also suggest continuing to open JIRAs that point to the PRs.

Alan.

> On Feb 8, 2017, at 11:33 AM, Julian Hyde  wrote:
> 
> Our current policy is that we accept patches attached to JIRA case and pull 
> requests to https://github.com/apache/calcite 
> . I would like to propose that we no 
> longer support patches.
> 
> Why? I argue that it makes the process easier for the committer. The pull 
> request implicitly does “git add” and “git remove”, whereas when applying a 
> patch you have to remember to apply these. The pull request comes in a 
> branch, so if I modify the code as I am reviewing it, I can easily save and 
> restore my state. Also, a pull request is “valid” as a contribution, from an 
> IP standpoint, even when not accompanied by a JIRA case.
> 
> Recently I went through 5 rounds of patches for a particular feature. I 
> couldn’t tell what had changed between one iteration of the patch and the 
> next (you can’t “diff" patches - you need to apply the patches to separate 
> git branches and diff the branches - yuck!). And I went through 3 test cycles 
> and 24 hours before I managed to “git add” all of the files. Yes, I did “git 
> status” and I missed the 2 new files among all of the “.orig” and “.rej” 
> files in my sandbox.
> 
> In summary. I propose that we accept contributions only as pull requests to 
> https://github.com/apache/calcite . If 
> they are non-trivial they should be accompanied by a JIRA case. Committers 
> can propose changes any way they like, as long as they commit the changes 
> themselves, but if they want to make it easier for others to review, they 
> should use either a personal git branch or a pull request.
> 
> Julian
> 

Re: how to get EXTRACT function working in CSVTest

[Julian Hyde]

Please log a bug for this.

You’re running into the problem I feared when I wrote "I'd rather that we 
convert java.sql.Date values when they enter the system” in 
https://issues.apache.org/jira/browse/CALCITE-1569 
. EXTRACT needs its input 
to be in internal format, which is a long (or Long) for a TIMESTAMP, an int (or 
Integer) for a DATE or TIME.

Julian


> On Feb 7, 2017, at 11:02 PM, hongbin ma  wrote:
> 
> hi experts,
> 
> According to this doc https://calcite.apache.org/docs/reference.html the
> EXTRACT function should work in Calcite. So I'm trying a query with EXTRACT
> in CSVTest:
> 
> @Test public void testSelectx() throws SQLException {
>  checkSql("model", "select extract(year from JOINEDAT) from EMPS ");
> }
> 
> the query failed due to:
> 
> java.lang.ClassCastException: java.sql.Date cannot be cast to
> java.lang.Integer
> 
> I also tried to change column JOINDAT's type to timestamp and datetime, but
> end up with similar exceptions.
> 
> Can you please help here? thx
> 
> 
> -- 
> Regards,
> 
> *Bin Mahone | 马洪宾*

Fwd: calcite regress a07c742 origin/master jdk9 status: 1 "[CALCITE-1619] CAST is ignored by rules pushing operators into DruidQuery"

[Julian Hyde]

Jesus,

Your recent commit broke the build due to a javadoc error. It shows up on JDK 8 
and 9, not sure about 7. Please run “mvn site” under JDK 8 or 9 before 
committing.

Julian


> Begin forwarded message:
> 
> Subject: calcite regress a07c742 origin/master jdk9 status: 1 "[CALCITE-1619] 
> CAST is ignored by rules pushing operators into DruidQuery" 
> Date: February 8, 2017 at 2:46:30 AM PST
> 
> [ERROR] 
> /home/jhyde/regress/calcite/druid/src/test/java/org/apache/calcite/test/DruidAdapterIT.java:806:
>  error: reference not found
> [ERROR] /** As {@link #testFilterSortDesc} but with a filter that cannot be 
> pushed
> [ERROR] ^
> [ERROR] 
> [ERROR] Command line was: /usr/lib/jvm/jdk9/bin/javadoc @options @packages
> [ERROR] 
> [ERROR] Refer to the generated Javadoc files in 
> '/home/jhyde/regress/calcite/target/site/testapidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> 
> status 1
> Finished at Wed Feb 8 02:46:30 PST 2017
> Subject: calcite regress a07c742 origin/master jdk9 status: 1 "[CALCITE-1619] 
> CAST is ignored by rules pushing operators into DruidQuery" 

Re: [DISCUSS] Patches

[Michael Mior]

+1 as well. I don't think it's a big burden on the contributor to open a
pull request and it makes things much easier for committers.

2017-02-08 14:33 GMT-05:00 Julian Hyde :

> Our current policy is that we accept patches attached to JIRA case and
> pull requests to https://github.com/apache/calcite <
> https://github.com/apache/calcite>. I would like to propose that we no
> longer support patches.
>
> Why? I argue that it makes the process easier for the committer. The pull
> request implicitly does “git add” and “git remove”, whereas when applying a
> patch you have to remember to apply these. The pull request comes in a
> branch, so if I modify the code as I am reviewing it, I can easily save and
> restore my state. Also, a pull request is “valid” as a contribution, from
> an IP standpoint, even when not accompanied by a JIRA case.
>
> Recently I went through 5 rounds of patches for a particular feature. I
> couldn’t tell what had changed between one iteration of the patch and the
> next (you can’t “diff" patches - you need to apply the patches to separate
> git branches and diff the branches - yuck!). And I went through 3 test
> cycles and 24 hours before I managed to “git add” all of the files. Yes, I
> did “git status” and I missed the 2 new files among all of the “.orig” and
> “.rej” files in my sandbox.
>
> In summary. I propose that we accept contributions only as pull requests
> to https://github.com/apache/calcite .
> If they are non-trivial they should be accompanied by a JIRA case.
> Committers can propose changes any way they like, as long as they commit
> the changes themselves, but if they want to make it easier for others to
> review, they should use either a personal git branch or a pull request.
>
> Julian
>
>

Re: [DISCUSS] Patches

[Vladimir Sitnikov]

Just to be a bit more clear: +1 to prefer pull requests over patch files.

Vladimir

ср, 8 февр. 2017 г. в 22:43, Vladimir Sitnikov :

> Julian>I would like to propose that we no longer support patches.
>
> +1
>
> Vladimir
>

Re: [DISCUSS] Patches

[Vladimir Sitnikov]

Julian>I would like to propose that we no longer support patches.

+1

Vladimir

Re: [DISCUSS] Patches

[Julian Hyde]

And one more thing: patches do not (necessarily) contain an author name and 
email address. The committer needs to fill these out when committing the patch. 
So, more back and forth ensues.

Julian

> On Feb 8, 2017, at 11:33 AM, Julian Hyde  wrote:
> 
> Our current policy is that we accept patches attached to JIRA case and pull 
> requests to https://github.com/apache/calcite 
> . I would like to propose that we no 
> longer support patches.
> 
> Why? I argue that it makes the process easier for the committer. The pull 
> request implicitly does “git add” and “git remove”, whereas when applying a 
> patch you have to remember to apply these. The pull request comes in a 
> branch, so if I modify the code as I am reviewing it, I can easily save and 
> restore my state. Also, a pull request is “valid” as a contribution, from an 
> IP standpoint, even when not accompanied by a JIRA case.
> 
> Recently I went through 5 rounds of patches for a particular feature. I 
> couldn’t tell what had changed between one iteration of the patch and the 
> next (you can’t “diff" patches - you need to apply the patches to separate 
> git branches and diff the branches - yuck!). And I went through 3 test cycles 
> and 24 hours before I managed to “git add” all of the files. Yes, I did “git 
> status” and I missed the 2 new files among all of the “.orig” and “.rej” 
> files in my sandbox.
> 
> In summary. I propose that we accept contributions only as pull requests to 
> https://github.com/apache/calcite . If 
> they are non-trivial they should be accompanied by a JIRA case. Committers 
> can propose changes any way they like, as long as they commit the changes 
> themselves, but if they want to make it easier for others to review, they 
> should use either a personal git branch or a pull request.
> 
> Julian
> 

[DISCUSS] Patches

[Julian Hyde]

Our current policy is that we accept patches attached to JIRA case and pull 
requests to https://github.com/apache/calcite 
. I would like to propose that we no longer 
support patches.

Why? I argue that it makes the process easier for the committer. The pull 
request implicitly does “git add” and “git remove”, whereas when applying a 
patch you have to remember to apply these. The pull request comes in a branch, 
so if I modify the code as I am reviewing it, I can easily save and restore my 
state. Also, a pull request is “valid” as a contribution, from an IP 
standpoint, even when not accompanied by a JIRA case.

Recently I went through 5 rounds of patches for a particular feature. I 
couldn’t tell what had changed between one iteration of the patch and the next 
(you can’t “diff" patches - you need to apply the patches to separate git 
branches and diff the branches - yuck!). And I went through 3 test cycles and 
24 hours before I managed to “git add” all of the files. Yes, I did “git 
status” and I missed the 2 new files among all of the “.orig” and “.rej” files 
in my sandbox.

In summary. I propose that we accept contributions only as pull requests to 
https://github.com/apache/calcite . If they 
are non-trivial they should be accompanied by a JIRA case. Committers can 
propose changes any way they like, as long as they commit the changes 
themselves, but if they want to make it easier for others to review, they 
should use either a personal git branch or a pull request.

Julian

Re: Bugs in website example code

[Damjan Jovanovic]

Alright, the Jira issue is:
https://issues.apache.org/jira/browse/CALCITE-1622

On Wed, Feb 8, 2017 at 7:32 PM, Josh Elser  wrote:

> Hi Damjan,
>
> Thanks for the patch! Might you be able to open up an issue on JIRA and
> attach this patch there (for the CALCITE project)?
>
> We use JIRA to track changes to the codebase and would like to make sure
> your contributions are recognized in a central location.
>
> Thanks in advance!
>
> - Josh
>
>
> Damjan Jovanovic wrote:
>
>> Hi
>>
>> On your http://calcite.apache.org/docs/ page, the example code is
>> completely broken: it doesn't add() either the ReflectiveSchema or the
>> JdbcSchema to the CalciteConnection's root schema, and the "name" and
>> "hr" JdbcSchema parameter for MySQL appear to need swapping.
>>
>> A patch against Git is attached.
>>
>> Otherwise, thank you for your otherwise awesome project :-).
>>
>> Damjan
>>
>>

[jira] [Created] (CALCITE-1622) Bugs in website example code

[Damjan Jovanovic (JIRA)]

Damjan Jovanovic created CALCITE-1622:
-

 Summary: Bugs in website example code
 Key: CALCITE-1622
 URL: https://issues.apache.org/jira/browse/CALCITE-1622
 Project: Calcite
  Issue Type: Bug
  Components: site
Reporter: Damjan Jovanovic
Assignee: Julian Hyde


On your website's http://calcite.apache.org/docs/ page, the example code is 
completely broken: it doesn't add() either the ReflectiveSchema or the 
JdbcSchema to the CalciteConnection's root schema, and the "name" and "hr" 
JdbcSchema parameter for MySQL appear to need swapping.

It took me hours to get Calcite working because of this :(.

I am attaching a patch.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Bugs in website example code

[Josh Elser]

Hi Damjan,

Thanks for the patch! Might you be able to open up an issue on JIRA and 
attach this patch there (for the CALCITE project)?


We use JIRA to track changes to the codebase and would like to make sure 
your contributions are recognized in a central location.


Thanks in advance!

- Josh

Damjan Jovanovic wrote:

Hi

On your http://calcite.apache.org/docs/ page, the example code is
completely broken: it doesn't add() either the ReflectiveSchema or the
JdbcSchema to the CalciteConnection's root schema, and the "name" and
"hr" JdbcSchema parameter for MySQL appear to need swapping.

A patch against Git is attached.

Otherwise, thank you for your otherwise awesome project :-).

Damjan

FINAL REMINDER: CFP for ApacheCon closes February 11th

[Rich Bowen]

Dear Apache Enthusiast,

This is your FINAL reminder that the Call for Papers (CFP) for ApacheCon
Miami is closing this weekend - February 11th. This is your final
opportunity to submit a talk for consideration at this event.

This year, we are running several mini conferences in conjunction with
the main event, so if you're submitting for one of those events, please
pay attention to the instructions below.

Apache: Big Data
* Event information:
http://events.linuxfoundation.org/events/apache-big-data-north-america
* CFP:
http://events.linuxfoundation.org/events/apache-big-data-north-america/program/cfp

Apache: IoT (Internet of Things)
* Event Information: http://us.apacheiot.org/
* CFP -
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp
(Indicate 'IoT' in the Target Audience field)

CloudStack Collaboration Conference
* Event information: http://us.cloudstackcollab.org/
* CFP -
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp
(Indicate 'CloudStack' in the Target Audience field)

FlexJS Summit
* Event information - http://us.apacheflexjs.org/
* CFP -
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp
(Indicate 'Flex' in the Target Audience field)

TomcatCon
* Event information - https://tomcat.apache.org/conference.html
* CFP -
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp
(Indicate 'Tomcat' in the Target Audience field)

All other topics and projects
* Event information -
http://events.linuxfoundation.org/events/apachecon-north-america/program/about
* CFP -
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp

Admission to any of these events also grants you access to all of the
others.

Thanks, and we look forward to seeing you in Miami!

-- 
Rich Bowen
VP Conferences, Apache Software Foundation
rbo...@apache.org
Twitter: @apachecon



(You are receiving this email because you are subscribed to a dev@ or
users@ list of some Apache Software Foundation project. If you do not
wish to receive email from these lists any more, you must follow that
list's unsubscription procedure. View the headers of this message for
unsubscription instructions.)

Bugs in website example code

[Damjan Jovanovic]

Hi

On your http://calcite.apache.org/docs/ page, the example code is
completely broken: it doesn't add() either the ReflectiveSchema or the
JdbcSchema to the CalciteConnection's root schema, and the "name" and "hr"
JdbcSchema parameter for MySQL appear to need swapping.

A patch against Git is attached.

Otherwise, thank you for your otherwise awesome project :-).

Damjan
diff --git a/site/_docs/index.md b/site/_docs/index.md
index f0c4afd..c1a5d71 100644
--- a/site/_docs/index.md
+++ b/site/_docs/index.md
@@ -48,8 +48,10 @@ info.setProperty("lex", "JAVA");
 Connection connection = DriverManager.getConnection("jdbc:calcite:", info);
 CalciteConnection calciteConnection =
 connection.unwrap(CalciteConnection.class);
-ReflectiveSchema.create(calciteConnection,
-calciteConnection.getRootSchema(), "hr", new HrSchema());
+SchemaPlus rootSchema = calciteConnection.getRootSchema();
+Schema schema = ReflectiveSchema.create(calciteConnection,
+rootSchema, "hr", new HrSchema());
+rootSchema.add("hr", schema);
 Statement statement = calciteConnection.createStatement();
 ResultSet resultSet = statement.executeQuery(
 "select d.deptno, min(e.empid)\n"
@@ -76,8 +78,8 @@ library. But Calcite can also process data in other data formats, such
 as JDBC. In the first example, replace
 
 {% highlight java %}
-ReflectiveSchema.create(calciteConnection,
-calciteConnection.getRootSchema(), "hr", new HrSchema());
+Schema schema = ReflectiveSchema.create(calciteConnection,
+rootSchema, "hr", new HrSchema());
 {% endhighlight %}
 
 with
@@ -88,8 +90,8 @@ BasicDataSource dataSource = new BasicDataSource();
 dataSource.setUrl("jdbc:mysql://localhost");
 dataSource.setUsername("username");
 dataSource.setPassword("password");
-JdbcSchema.create(calciteConnection.getRootSchema(), "name", dataSource,
-null, "hr");
+Schema schema = JdbcSchema.create(rootSchema, "hr", dataSource,
+null, "name");
 {% endhighlight %}
 
 and Calcite will execute the same query in JDBC. To the application,