Re: Re: JoinPushThroughJoinRule not applied on plan

Referring the link, it says 'If either join is not inner, we cannot proceed', so 'or' condition. In my case, one is inner join and another one is outer join On 2018/05/14 20:47:31, "Haisheng Yuan" wrote: > The associativity rule only applies for inner join. In your case, you have an > outer jo

Re: SqlValidator can't prohibit the data type of ORDER BY with RANGE prober.

I think calcite shouldn't prohibit the compound ORDER BY for the window( *UNBOUNDED PRECEDING and current row*). John Fang 于2018年5月15日周二 上午11:05写道： > *Thanks for Julian.* > > *I test those query in Oracle for the table test(id int, name varchar(50), > score int).* > > > * For range based vachar

Re: SqlValidator can't prohibit the data type of ORDER BY with RANGE prober.

*Thanks for Julian.* *I test those query in Oracle for the table test(id int, name varchar(50), score int).* * For range based vachar type of ORDER BY, those query's behavior is same with Oracle.* *In Oracle:* query-1: select id, count(1) over (partition by id order by name range between UNBOU

Mongo, Elasticsearch or Solr adapters

Colleagues, I am getting ready to engage in the next range of research with Calcite and textually accessible resources through Calcite. I am considering Mongo, Elasticsearch and Solr. Can anyone here tell me more about the maturity and stability of the Mongo, Elasticsearch, and Solr adapters? T

Re: CalcitePrepare inconsistantly applies parser config

I saw CALCITE-1525 , which I think is the issue you are referring to. Apache Beam is currently using Frameworks, but we've reimplimented much of CalcitePrepare (parse/convert/executeDdl) on top of it. I'm in the process of adding JDBC support to B

Calcite-Master - Build # 273 - Still Failing

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

Re: Re: JoinPushThroughJoinRule not applied on plan

The associativity rule only applies for inner join. In your case, you have an outer join. Check this out:https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/JoinPushThroughJoinRule.java#L139 Thanks ~Haisheng Yuan --

Re: JoinPushThroughJoinRule not applied on plan

Check yours intermediate RelNode plan, which is going to be improved by this rule. The operands and their ordering are important in matching of the rules. https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/JoinPushThroughJoinRule.java#L87 >From your case

[jira] [Created] (CALCITE-2309) Dialects: Hive dialect does not support charsets in constants

Gopal V created CALCITE-2309: Summary: Dialects: Hive dialect does not support charsets in constants Key: CALCITE-2309 URL: https://issues.apache.org/jira/browse/CALCITE-2309 Project: Calcite Is

Re: CalcitePrepare inconsistantly applies parser config

You are correct; we should be more consistent. I think there’s a JIRA case that we should use the same mechanism for preparing queries inside the JDBC driver (i.e. driven by CalcitePrepare) as outside a JDBC driver (i.e. using Frameworks). But that would be a lot of work. If you can find some s

CalcitePrepare inconsistantly applies parser config

I've noticed that the CalcitePrepare interface creates a parser in both the parse and prepare paths, but only the prepare path applies the custom parser config from the context. Is this intentional? Shouldn't both paths use the config from the context? Andrew

Re: How to pass a custom object as an operand to the schema factory ?

Even though you can pass custom objects, you should not. We might want to create a connection via a JDBC connect string, which only allows strings. Or via an RPC. I’d limit it to JSON-serializable values - ordered map, ordered list, string, boolean, numeric, null. If you want to pass a complex

Re: SqlValidator can't prohibit the data type of ORDER BY with RANGE prober.

I still think that the first query is invalid and the second is valid. The first query requires not just a range but a distance. You can compute the distance between two numeric or timestamp values (by subtracting them) but not between two varchar values. The second query requires a “unbounded p

Re: calcite inner join error

You're correct that it means that the input must be of the Elasticsearch convention. But you shouldn't need to create a converter as the rule which creates ElasticsearchProject should only match when the input is already of the Elasticsearch convention. Elasticsearch doesn't need to support joins a

Re: calcite inner join error

The assertion mandates that the input of the ElasticSearchProject be of the ElasticSearch convnetion. I believe you need to create a converter that changes the Join node convention to ElasticSearch convention but this means that ElasticSearch can run joins, which I don't know about. Or, you need to

Re: calcite inner join error

Attachments can't be sent to this list. Either include attachments in the body of the email or post a link to something like a GitHub gist. -- Michael Mior mm...@uwaterloo.ca Le lun. 14 mai 2018 à 08:22, liuxiaorui <501256...@qq.com> a écrit : > my calcite version is 1.15.0 , elasticsearch

calcite inner join error

my calcite version is 1.15.0 , elasticsearch verison is 5.3.0 and model file is model1.json in attachment. the mapping of table1 : {"db":{"mappings":{"table1":{"properties":{"birthday":{"type":"date"},"id":{"type":"integer"},"int1":{"type":"integer"},"str1":{"type":"text"}} the mapping

SqlValidator can't prohibit the data type of ORDER BY with RANGE prober.

win("window w as (order by ename range ^100^ preceding)") .fails("Data type of ORDER BY prohibits use of RANGE clause"); The query will be prohibited in calcite because the ename's type is varchar(20). But the followed query will be allowed in calcite. win("window w as (partition by ename ord