Re: Calcite - JDK 8 and Use of Guava

In general I would agree that we should replace Guava with JDK features if the JDK has them. However, we must preserve compatibility, so if an API uses Guava Function or Predicate or Supplier or ImmutableList then we should probably keep it that way. Or let’s discuss it. Converting

Calcite - JDK 8 and Use of Guava

There is a discussion in SOLR-11763 about Guava and limiting its use by replacing with native JDK 8 alternatives. Since Calcite 0.16.0 is now on minimum JDK 8 this looks to be viable. CALCITE-2259 identifies a few other JDK 8 nice to haves. One example looks to be: *

[jira] [Created] (CALCITE-2282) Allow OperatorTable to be pluggable in the parser

Sudheesh Katkam created CALCITE-2282: Summary: Allow OperatorTable to be pluggable in the parser Key: CALCITE-2282 URL: https://issues.apache.org/jira/browse/CALCITE-2282 Project: Calcite

[jira] [Created] (CALCITE-2281) TIMESTAMPADD(MICROSECOND, ...) returns incorrect results

Sudheesh Katkam created CALCITE-2281: Summary: TIMESTAMPADD(MICROSECOND, ...) returns incorrect results Key: CALCITE-2281 URL: https://issues.apache.org/jira/browse/CALCITE-2281 Project: Calcite

[jira] [Created] (CALCITE-2280) "Super-liberal" parser that accepts all SQL dialects

Julian Hyde created CALCITE-2280: Summary: "Super-liberal" parser that accepts all SQL dialects Key: CALCITE-2280 URL: https://issues.apache.org/jira/browse/CALCITE-2280 Project: Calcite

Re: [ANNOUNCE] New committer: Kevin Risden

Congrats, Kevin! On 26/04/2018 2:36 AM, Julian Hyde wrote: Apache Calcite's Project Management Committee (PMC) has invited Kevin Risden to become a committer, and we are pleased to announce that he has accepted. Kevin has been active in the Calcite community for some time, picking up a lot of

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

Thank you! That helped a lot. Thanks, Gelbana On Wed, Apr 25, 2018 at 12:00 PM, Stamatis Zampetakis wrote: > Hi Gelbana, > > I haven't looked at your snippet but if you want to debug into generated > code have a look at the following link: >

Re: How to create user-defined data types in calcite?

Good point about the rebase. I would suggest that as the proposed process since it means we don't lose changes mistakenly committed to site. I would suggest that after the rebase, "git log master..site" to be run to ensure that it produces no output. So the only purpose of the rebase vs "git reset

Re: How to create user-defined data types in calcite?

I think if you rebase “site” onto “master”, git will spot commits that are already on “site”. $ git checkout site $ git rebase -i origin master All being well, site should end up identical to master after the rebase. So force-push is not scary. Julian > On Apr 25, 2018, at 11:31 AM, Michael

Re: How to create user-defined data types in calcite?

Sure, I understand. But no one can do a fast-forward merge to the site branch unless they know for sure that nothing in there is going to make changes to the site that shouldn't be deployed. And then we're back to whoever updates the site needing to already know what should be deployed. I'm

Re: How to create user-defined data types in calcite?

I don't see how the sync with the master branch could be a fast-forward merge. This isn't possible if commits just affecting the site have been cherry picked since the last sync. -- Michael Mior mm...@uwaterloo.ca 2018-04-25 14:13 GMT-04:00 Julian Hyde : > My personal opinion

Re: How to create user-defined data types in calcite?

My personal opinion about (non-fast-forward) merge commits: never do them. If site and master can be on the same line (i.e. if there is no new product-related changes to the site) then they should be. If they need to diverge, then cherry-pick individual commits from master to site. I added

Re: How to create user-defined data types in calcite?

Sure. Although there (at least) two ways of syncing site with master. One being to force push master to the site branch and the other to merge the master branch into site. I do kind of like the idea of the force push just to avoid having the site branch be eternally filled with a bunch of merge

Re: How to create user-defined data types in calcite?

A force-push to the “site” branch each release would not be a terrible thing. (Force-pushes are only suspect when they are to the master branch or a release branch.) Before the release, the release manager should make sure that edits on “site" have made it to “master”. Right after the release,

Re: How to create user-defined data types in calcite?

Sounds reasonable to me. I like that better than the current approach of whoever is updating the site needing to maintain mental state on what is and isn't ready to be posted. We should of course add documentation for this as part of the release process. We also should make clear in the site

Re: How to create user-defined data types in calcite?

I am adding Kevin to the committers list, and I am seeing the problem of mixed changes - recently Michael has edited the site to add two PMC members, and Shuyi has added documentation for CREATE TYPE. We want the former to appear on the site, but the latter should wait until the release. I

[ANNOUNCE] New committer: Kevin Risden

Apache Calcite's Project Management Committee (PMC) has invited Kevin Risden to become a committer, and we are pleased to announce that he has accepted. Kevin has been active in the Calcite community for some time, picking up a lot of “somebody need to do this” tasks and improving the quality of

Re: Druid Adapter - Error Prone checking result

Thanks Kevin! On 4/24/18, 7:43 PM, "Kevin Risden" wrote: Created CALCITE-2279 Kevin Risden On Tue, Apr 24, 2018 at 1:33 PM, Kevin Risden wrote: > No JIRA yet. Will create one for this. > > Kevin Risden > >

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

Hi Gelbana, I haven't looked at your snippet but if you want to debug into generated code have a look at the following link: https://calcite.apache.org/docs/howto.html#debugging-generated-classes-in-intellij Best, Stamatis 2018-04-21 14:07 GMT+02:00 Muhammad Gelbana : >