Re: [DISCUSS] Towards Calcite 1.23.0
IIRC, I am the release manager for 1.23.0. I think CALCITE-3896 (top-down trait request) is in good shape, it will be nice if it can go into 1.23.0. Can someone help review? On 2020/05/04 22:58:25, Stamatis Zampetakis wrote: > Hello, > > Calcite 1.22.0 was released about 2 months ago (on March 5, 2020). During > the vote we said to try to have a release sooner than usual so I am > launching the discussion now hoping we could get to 1.23.0 rather soon. > > I was checking the status of the current release [1] and we have already > over 100 resolved issues with 91 fixes so it is already pretty big. > > I know that there quite a few discussions in progress so it would be good > to see how many of the ongoing cases should be fixed for 1.23.0. > > More importantly do we have a release manager for 1.23.0? > > Best, > Stamatis > > [1] > https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950 >
Re: [DISCUSS] Towards Calcite-Avatica 1.17.0
There hasn't been any commits to the repository since I last sent the message. Let's focus on Calcite 1.23.0 and revisit Avatica after the Calcite release. Francis On 20/04/2020 8:32 am, Francis Chuang wrote: Hey everyone, I am planning to make rc0 available for voting towards the end of April / start of May. How does this look in terms of timing? Francis On 12/04/2020 2:51 am, Stamatis Zampetakis wrote: Thanks again for taking the lead on this Francis! Personally, I am quite busy these days but will do my best to check 1-2 PRs. On Fri, Apr 10, 2020 at 2:57 PM Josh Elser wrote: Always a good idea. I'll add this to my list and see if I can help get any committed. It's been a while since I've looked at the list. On 4/8/20 7:59 PM, Francis Chuang wrote: The last avatica release was in December last year. From activity on our mailing lists and the Calcite repository, it feels like there's currently a lull and things aren't as active. Would this be a good opportunity to work on Avatica and push a release out? There are currently 10 open PRs for Avatica [1] and I think if they are reviewed and merged, it wold be possible to close a huge chunk of them. I am happy to be RM for this release, but will need help from the community to review and merge those PRs. Francis [1] https://github.com/apache/calcite-avatica/pulls
[DISCUSS] Towards Calcite 1.23.0
Hello, Calcite 1.22.0 was released about 2 months ago (on March 5, 2020). During the vote we said to try to have a release sooner than usual so I am launching the discussion now hoping we could get to 1.23.0 rather soon. I was checking the status of the current release [1] and we have already over 100 resolved issues with 91 fixes so it is already pretty big. I know that there quite a few discussions in progress so it would be good to see how many of the ongoing cases should be fixed for 1.23.0. More importantly do we have a release manager for 1.23.0? Best, Stamatis [1] https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333950
Calcite-Master - Build # 1735 - Still Failing
The Apache Jenkins build system has built Calcite-Master (build #1735) Status: Still Failing Check console output at https://builds.apache.org/job/Calcite-Master/1735/ to view the results.
[jira] [Created] (CALCITE-3971) Support Calc in RelMdColumnOrigins
xzh_dz created CALCITE-3971:
---
Summary: Support Calc in RelMdColumnOrigins
Key: CALCITE-3971
URL: https://issues.apache.org/jira/browse/CALCITE-3971
Project: Calcite
Issue Type: Wish
Reporter: xzh_dz
In my project, we often use `RelColumnOrigin` to find metadata information for
columns.
When i try to get origin column , and i got exception as below, the exception
can be reproduced.
{code:java}
final String sql = "select name,deptno from dept";
final RelNode relNode = convertSql(sql);
final HepProgram program = new HepProgramBuilder().
addRuleInstance(ProjectToCalcRule.INSTANCE).build();
final HepPlanner planner = new HepPlanner(program);
planner.setRoot(relNode);
final RelNode calc = planner.findBestExp();
final RelMetadataQuery mq = calc.getCluster().getMetadataQuery();
final RelColumnOrigin nameColumn = mq.getColumnOrigin(calc, 0);
assertThat(nameColumn.getOriginColumnOrdinal(), is(1));
{code}
java.lang.NullPointerException
at
org.apache.calcite.test.RelMetadataTest.testCalcColumnOriginsTable(RelMetadataTest.java:391)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:675)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Calcite-Master - Build # 1734 - Failure
The Apache Jenkins build system has built Calcite-Master (build #1734) Status: Failure Check console output at https://builds.apache.org/job/Calcite-Master/1734/ to view the results.
[jira] [Created] (CALCITE-3970) Table-valued function TUMBLE uses non-standard syntax
Viliam Durina created CALCITE-3970:
--
Summary: Table-valued function TUMBLE uses non-standard syntax
Key: CALCITE-3970
URL: https://issues.apache.org/jira/browse/CALCITE-3970
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.22.0
Reporter: Viliam Durina
The currently supported syntax is this:
{code:java}
SELECT * FROM TABLE(TUMBLE(TABLE my_table, ...
{code}
But the SQL standard specifies that {{my_table}} must be in parentheses, such
as here:
{code:java}
SELECT * FROM TABLE(TUMBLE(TABLE(my_table), ...
{code}
The second syntax is currently rejected with:
{code:none}
Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException:
Encountered "(" at line 1, column 33.
Was expecting one of:
...
...
...
...
...
{code}
I followed this document:
[http://standards.iso.org/ittf/PubliclyAvailableStandards/c069776_ISO_IEC_TR_19075-7_2017.zip]
The {{TABLE}} clause acts in both ways: (1) to convert a table value to a table
object (when used in the {{FROM}} clause to convert the function result) and
(2) to convert a table object to a table value (when used to convert arguments
to a function).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
