Re: [VOTE] [CALCITE-3559] Drop HydromaticFileSetCheck, upgrade Checkstyle

Michael>wee could always pull the relevan code into Calcite Do you realize Checkstyle does not support source-code based plugins? It requires jar files. It would be non-trivial to build a custom checkstyle plugin in the beginning of Calcite build and use it later in the same build.

Re: [VOTE] [CALCITE-3559] Drop HydromaticFileSetCheck, upgrade Checkstyle

Danny> it normalize the file end pretty well(avoid all kinds of file end) I just realized there's JIRA which answers it: https://issues.apache.org/jira/browse/CALCITE-490 One can't avoid 'file end'. The file has to end with something, and the use of '// End' does not avoid file end. '// End

Re: [VOTE] [CALCITE-3559] Drop HydromaticFileSetCheck, upgrade Checkstyle

Project-specific rules are missing, thus general rules apply: https://www.apache.org/foundation/voting.html#votes-on-code-modification , https://www.apache.org/foundation/voting.html It says: > In this scenario, a negative vote constitutes a veto

[jira] [Created] (CALCITE-3570) Support MutableSnapshot in MutableRel

xzh_dz created CALCITE-3570: --- Summary: Support MutableSnapshot in MutableRel Key: CALCITE-3570 URL: https://issues.apache.org/jira/browse/CALCITE-3570 Project: Calcite Issue Type: Wish

Re: [VOTE] [CALCITE-3559] Drop HydromaticFileSetCheck, upgrade Checkstyle

I’m not voting, I just want to say something to this HydromaticFileSetCheck >* HydromaticFileSetCheck produces hard to understand messages. I guess many of you have faced "Open parentheses exceed closes by 2 or more [HydromaticFileSet]" issue, and I guess you it took you a lot to understand what

Re: [VOTE] [CALCITE-3559] Drop HydromaticFileSetCheck, upgrade Checkstyle

Vladimir created the confusion by starting a vote on a commit, and without specifying the rules of the vote (unanimous, majority, lazy consensus). Then later on he referred to it as a discussion. Assuming that this was a discussion, my “-1” meant “I’m generally against this idea”. It’s

Re: [VOTE] [CALCITE-3559] Drop HydromaticFileSetCheck, upgrade Checkstyle

I'll leave Julian to clarify whether or not the -1 was intended to be a veto, but as you noted, Julian expressed some concern in the PR and the associated JIRA. If we are voting, I'm currently -0 because I haven't found checkstyle violations to be significant problem for me and I don't like the

Re: [VOTE] [CALCITE-3559] Drop HydromaticFileSetCheck, upgrade Checkstyle

I'm not following many Apache projects but in those that I do I don't see votes for code modifications very often. There is always some tension whenever somebody calls for a vote so personally I would prefer if could go without. I'm sure Vladimir did it with good intentions so that the discussion

Re: lex parameter does not get taken into account for views

As I remarked in the Jira, we don’t want views to be expanded according to the rules of the current connection. Views belong to the schema, and the schema is shared among many connections, which may have different lex parameters. > On Dec 1, 2019, at 10:06 PM, XING JIN wrote: > > Filed a

Re: [DISCUSS] Towards Avatica 1.16.0

Hi everyone, Just a quick reminder that I am making rc0 available for voting tomorrow. If you need to get any change in, or if the time-frame is inconvenient, please let me know. Francis On 2/12/2019 9:07 am, Francis Chuang wrote: The Avatica 1.16.0 release seems to be a bit overdue. I plan

Re: Release managers

Sure, take 1.24. By the way, if people are eager to be release managers, we might need some for Avatica release-train. > On Dec 2, 2019, at 5:11 PM, Chunwei Lei wrote: > > It's great to know that committers can be release manager. > I volunteer to be the release manager if there is a

Re: [DISCUSS] Towards Calcite 1.22

I don’t mind whether the release happens in December or January, but either way, let’s start burning down the backlog of PRs now. > On Dec 2, 2019, at 11:43 PM, Enrico Olivelli wrote: > > Andrei > > Il mar 3 dic 2019, 08:21 Rui Wang > ha scritto: > >> Thank you

Re: [VOTE] [CALCITE-3559] Drop HydromaticFileSetCheck, upgrade Checkstyle

Michael>I didn't interpret Jullian's -1 as a veto > https://www.apache.org/foundation/voting.html#Veto > A code-modification proposal may be stopped dead in its tracks by a -1 vote by a qualified voter. > This constitutes a veto, and it cannot be overruled nor overridden by anyone. > Vetos stand

Re: [VOTE] [CALCITE-3559] Drop HydromaticFileSetCheck, upgrade Checkstyle

I didn't interpret Jullian's -1 as a veto. I agree that we generally don't need to vote on code changes. I don't believe we ever voted on the Gradle migration and IMO that was a much moree significant change. -- Michael Mior mm...@apache.org Le mer. 4 déc. 2019 à 14:28, Vladimir Sitnikov a

Re: [VOTE] [CALCITE-3559] Drop HydromaticFileSetCheck, upgrade Checkstyle

Julian>-1 I see your pain, however, please remember: ASF> https://www.apache.org/foundation/voting.html#Veto ASF> A veto without a justification is invalid and has no weight The PR is a clear improvement, and we can always make it better (e.g. by committing more code). We even can roll it back

Re: [VOTE] [CALCITE-3559] Drop HydromaticFileSetCheck, upgrade Checkstyle

It’s unusual to vote on a code change. We could just have a discussion, and reach consensus about whether the PR is a net benefit. -1 > On Dec 4, 2019, at 2:30 AM, Vladimir Sitnikov > wrote: > > Hi, > > I suggest we drop HydromaticFileSetCheck from the Checkstyle configuration. > It was a

[jira] [Created] (CALCITE-3569) IndexOutOfBoundsException when pushing FALSE filter to view

Chunwei Lei created CALCITE-3569: Summary: IndexOutOfBoundsException when pushing FALSE filter to view Key: CALCITE-3569 URL: https://issues.apache.org/jira/browse/CALCITE-3569 Project: Calcite

[jira] [Created] (CALCITE-3568) BigQuery SQL dialect doesn't support nested aggregates.

Divyanshu Srivastava created CALCITE-3568: - Summary: BigQuery SQL dialect doesn't support nested aggregates. Key: CALCITE-3568 URL: https://issues.apache.org/jira/browse/CALCITE-3568 Project:

[VOTE] [CALCITE-3559] Drop HydromaticFileSetCheck, upgrade Checkstyle

Hi, I suggest we drop HydromaticFileSetCheck from the Checkstyle configuration. It was a great journey (thanks Julian for HydromaticFileSetCheck), however, lots of tools have improved since then, so we could upgrade to the better tooling now. [ ] +1, drop HydromaticFileSetCheck, just do it [ ]

[jira] [Created] (CALCITE-3567) UNNEST(RECORDTYPE(MAP)) not supported

Wang Yanlin created CALCITE-3567: Summary: UNNEST(RECORDTYPE(MAP)) not supported Key: CALCITE-3567 URL: https://issues.apache.org/jira/browse/CALCITE-3567 Project: Calcite Issue Type: Bug

[jira] [Created] (CALCITE-3566) Support EnumerableIntersect and EnumerableMinus convert to Logical

xzh_dz created CALCITE-3566: --- Summary: Support EnumerableIntersect and EnumerableMinus convert to Logical Key: CALCITE-3566 URL: https://issues.apache.org/jira/browse/CALCITE-3566 Project: Calcite

[jira] [Created] (CALCITE-3565) Explicitly cast assignable operand types to decimal for udf

Feng Zhu created CALCITE-3565: - Summary: Explicitly cast assignable operand types to decimal for udf Key: CALCITE-3565 URL: https://issues.apache.org/jira/browse/CALCITE-3565 Project: Calcite

[jira] [Created] (CALCITE-3564) Make operand type check accurate for some functions in validation phase

Feng Zhu created CALCITE-3564: - Summary: Make operand type check accurate for some functions in validation phase Key: CALCITE-3564 URL: https://issues.apache.org/jira/browse/CALCITE-3564 Project: Calcite

[jira] [Created] (CALCITE-3563) Convert function operand type to match implementation if necessary in runtime

Feng Zhu created CALCITE-3563: - Summary: Convert function operand type to match implementation if necessary in runtime Key: CALCITE-3563 URL: https://issues.apache.org/jira/browse/CALCITE-3563 Project: