Re: [DISCUSS] Towards Calcite 1.26.0

The schedule sounds good to me, thanks Ruben for being the release manager ~ Best, Danny Chan 在 2020年9月30日 +0800 AM3:44，Julian Hyde ，写道： > > What is the status on 4279 (SEARCH operator into Druid)? > > Working on it. > > > On Sep 29, 2020, at 11:58 AM, Ruben Q L wrote: > > > > Thanks for the

Re: [DISCUSS] Sarg (search argument) to generalize and replace IN in RexCall

There is already an issue requesting RangeSet taken out of beta: https://github.com/google/guava/issues/3376 > On Sep 29, 2020, at 1:41 PM, Stamatis Zampetakis wrote: > > If it is a big concern can't we mark our own classes/fields relying on Beta

Re: [DISCUSS] Sarg (search argument) to generalize and replace IN in RexCall

If it is a big concern can't we mark our own classes/fields relying on Beta APIs as experimental and subject to change? In [1] they also say the following about Beta APIs: "All this said, @Beta features tend to remain relatively stable. If we decide to delete a @Beta feature, we will typically

Re: [DISCUSS] Sarg (search argument) to generalize and replace IN in RexCall

For the record, the Druid adapter has used RangeSet for a long while, and it made sense, because Druid was doing tricky computations on date ranges. Introducing Sargs brought that style to other parts of Calcite. If someone was to build an adapter similar to the Druid adapter, based on 1.26,

Re: [DISCUSS] Sarg (search argument) to generalize and replace IN in RexCall

Julian>The vast majority of clients who use Sarg (or expressions that contain Sarg) will not reference RangeSet Julian> directly and therefore would not be impacted. So I think it’s an acceptable risk. Well, it is hard to tell, however, I know Druid is using Sargs, and, I guess, Druid is one

Re: [DISCUSS] Sarg (search argument) to generalize and replace IN in RexCall

> On Sep 29, 2020, at 11:40 AM, Vladimir Sitnikov > wrote: > > Julian>Suppose - worst case scenario - that Guava 30 removes RangeSet. The > solution would be for us to copy RangeSet and enough dependent classes into > Calcite to serve our needs > > Then all the clients would have to adjust

Re: [DISCUSS] Towards Calcite 1.26.0

Thanks for the feedback, Julian. I will keep in mind changing 'MacOS' to 'macOS' in the release notes. What is the status on 4279 (SEARCH operator into Druid)? Ruben Le mar. 29 sept. 2020 à 19:51, Julian Hyde a écrit : > Thursday sounds good. > > I am working on getting 3752 (PIVOT) and 4238

Re: [DISCUSS] Towards Calcite 1.26.0

Thursday sounds good. I am working on getting 3752 (PIVOT) and 4238 (parser configuration) passing CI and merged. (4238 changes buildSrc and that seems to freak out Gradle’s cache in CI.) For 4034 (InnoDB adapter), I am waiting for Xu (neoremind) to fix a remaining bug. Don’t hold the release

Re: [DISCUSS] Sarg (search argument) to generalize and replace IN in RexCall

Julian>Suppose - worst case scenario - that Guava 30 removes RangeSet. The solution would be for us to copy RangeSet and enough dependent classes into Calcite to serve our needs Then all the clients would have to adjust packages because we can't copy Guava code and keep Guava's package names.

Re: [DISCUSS] Sarg (search argument) to generalize and replace IN in RexCall

I knew the risks going in, and I’m not very concerned. Suppose - worst case scenario - that Guava 30 removes RangeSet. The solution would be for us to copy RangeSet and enough dependent classes into Calcite to serve our needs. Our support for Guava 30 would be delayed by a month or two. Sarg

Re: ApacheCon 2020 talks relevant to Apache Calcite

Perhaps not relevant to a lot of Calcite folks, but I'll be giving a talk on Thursday where Calcite will make an appearance :) https://apachecon.com/acah2020/tracks/community.html#R1855 -- Michael Mior mm...@apache.org Le lun. 28 sept. 2020 à 10:18, Stamatis Zampetakis a écrit : > > Hi all, >

Re: [DISCUSS] Sarg (search argument) to generalize and replace IN in RexCall

Apparently, RangeSet is a @Beta API in Guava, and they stress that @Beta APIs should not be used in libraries. I suggest we do something with that, otherwise, it results in a case where Calcite enforces all the consumers to depend on @Beta API which might disappear or drift. See

[jira] [Created] (CALCITE-4296) Materialization recognition fail, cannot match Calc on top of materialized view

xzh_dz created CALCITE-4296: --- Summary: Materialization recognition fail, cannot match Calc on top of materialized view Key: CALCITE-4296 URL: https://issues.apache.org/jira/browse/CALCITE-4296 Project:

Re: Hi. Calcaite help please

Avatica [1] is used as a HTTP server to serve requests. It talks in protobuf and JSON with the client. Perhaps dig around Avatica's code to see if you can find what you're looking for. [1] https://github.com/apache/calcite-avatica On 29/09/2020 6:46 pm, Test Last wrote: Hello I have been

Hi. Calcaite help please

Hello I have been looking through the code and I can not seem to find the part where the messages come into the server still in protobuf form. So before it`s parsed by protobufs? Scala is all a bit new to me so I am not sure what to look for. I also want to find the position of the code that

[jira] [Created] (CALCITE-4295) The minMin function of CompositeOperandTypeChecker should returns the minimum of lower bound of all SqlOperandCountRange

Zhenghua Gao created CALCITE-4295: - Summary: The minMin function of CompositeOperandTypeChecker should returns the minimum of lower bound of all SqlOperandCountRange Key: CALCITE-4295 URL:

[jira] [Created] (CALCITE-4294) Use JTS rather than ESRI as the underlying library for geospatial (ST_) functions

Julian Hyde created CALCITE-4294: Summary: Use JTS rather than ESRI as the underlying library for geospatial (ST_) functions Key: CALCITE-4294 URL: https://issues.apache.org/jira/browse/CALCITE-4294