Confusion about the GeoFunctions

Hi all, Recently, the flink community aims to add some OpenGIS functions (see FLINK-9219 ) provided in CALCITE-1968 . For some reasons, we plan to implement some Flink Geom types (as illustrated

Re: Ordering of columns during a join

Please let me know. I am blocked on CALCITE - 500 on this, so it will be great if I could get some advise here. Thanks On Tue, May 22, 2018 at 7:23 PM, Atri Sharma wrote: > I agree, however, the cast failures are something I am not sure about. If > you look at the output

Re: Best practice for exhaustive planning

For most queries, the only thing you should need to implement is a scan and the rest can usually be implemented by Calcite. It would be good if you have a specific example of a query that fails. -- Michael Mior mm...@uwaterloo.ca Le mar. 22 mai 2018 à 19:01, Kenneth Knowles

Re: Reviewers

I think this is a reasonable idea. We should have owners conceptually for each component, but not physically assigned. Also, I like the idea of sending an email to dev if no one engaged with 24 hours, maybe add a title like [REQUEST REVIEW] [], so committers can better filter the emails. On Tue,

Re: Best practice for exhaustive planning

Bumping this, as it ended up in spam for some people. Kenn On Tue, May 15, 2018 at 9:26 AM Kenneth Knowles wrote: > Hi all, > > Beam SQL uses Calcite for parsing and (naive) planning. Currently it is > pretty easy to write a SQL query that parses and causes a "could not plan"

Calcite-Master - Build # 279 - Still Failing

The Apache Jenkins build system has built Calcite-Master (build #279) Status: Still Failing Check console output at https://builds.apache.org/job/Calcite-Master/279/ to view the results.

Re: Reviewers

I think this is a good idea. Francis On 23/05/2018 3:09 AM, Julian Hyde wrote: It gets assigned to me because I am owner of the “core” component in JIRA. Should we remove owners from all components? On May 21, 2018, at 6:04 PM, Alex Xu wrote: Agree ！

[jira] [Created] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

Kevin Minder created CALCITE-2322: - Summary: Add fetch size support to connection url and JDBC statement Key: CALCITE-2322 URL: https://issues.apache.org/jira/browse/CALCITE-2322 Project: Calcite

Calcite-Master - Build # 278 - Failure

The Apache Jenkins build system has built Calcite-Master (build #278) Status: Failure Check console output at https://builds.apache.org/job/Calcite-Master/278/ to view the results.

Re: Reviewers

It gets assigned to me because I am owner of the “core” component in JIRA. Should we remove owners from all components? > On May 21, 2018, at 6:04 PM, Alex Xu wrote: > > Agree ！ > > ptr.bo...@gmail.com 于2018年5月22日 周二上午4:26写道： > >> Hello, >> >> I've

Re: [v1.15] A NPE that looks inevitable !

I found this issue and it explains what I was facing: https://issues.apache.org/jira/browse/CALCITE-1436 I excluded the bindable aggregate rule and the query executed fine @Override public void register(RelOptPlanner planner) { RULES.forEach(planner::addRule);

Re: Ordering of columns during a join

I agree, however, the cast failures are something I am not sure about. If you look at the output bring generated, it is definitely incorrect . My main query is, is it possible to change the order of inputs to EnumerableJoin's implementation for a commutative join? If it is not, is there a reason

Re: Delete and Update projecting unnecessary columns

Hi, Just bumping this question. We have worked around this issue in downstream code to remove the extra projection columns, but I am still wondering if there is some easier way to get the same effect in calcite. I am assuming calcite projects all the columns to be used as a 'natural key'

Re: Ordering of columns during a join

For more context, testEquiThetaJoin fails due to the following diff in output: java.lang.AssertionError: Expected: is "empid=100; name=Sales; name=Bill\nempid=150; name=Sales; name=Sebastian\nempid=110; name=Sales; name=Theodore\n" but: was "empid=10; name=Bill; name=100\nempid=10;

Ordering of columns during a join

Hi All, As an experiment, I switched the order of inputs to EnumerableDefaults::join_ during the implementation stage of EnumerableJoin if the Join type is Inner. Since there will be no need to generate nulls on either side, I would assume that the choice of the side being built and the side

Needs Review - CALCITE-2320

Hello, Please review a bug fix: Issue - https://issues.apache.org/jira/browse/CALCITE-2320 Pull - https://github.com/apache/calcite/pull/693 Thank you. -- Piotr Bojko http://about.me/ptr.bojko