Re: [DISCUSS] Where do we draw the line?

[Albert]

haven't contributed a while.
I mostly agree with Julian's comment. I'm not a native English speaker and
I think that line of comment could be interpreted as `humorous` or may be
at least intended to.
if I was contributing that feature, I would care more if there are comments
to help push my contribution into the project. so consensus matters, things
needs to be done.

maybe Zoltan could share his feel on that review, and Vladimir could act
correspondingly.



On Fri, Oct 19, 2018 at 8:23 AM Ashutosh Chauhan 
wrote:

> I have not contributed to Calcite in a while but I keep up with whats going
> in project and actively follow mailing list and jiras of interest.
> I concur with Josh that it is public shaming and bullying. This is not
> acceptable. Also, this is not an exception but pattern which tells me that
> it will continue in future too.
> This is not in line with ASF code of conduct and respectful dialog expected
> in community.
>
> Thanks,
> Ashutosh
>
> On Thu, Oct 18, 2018 at 4:24 PM Michael Mior  wrote:
>
> > You can see that I already responded to the comment and I don't really
> have
> > many further thoughts. I do agree though that it's true that this could
> > have been intended humorously and my reaction didn't acknowledge that.
> That
> > said, it's of course worth considering with comments intended to be
> > humorous how they will be perceived.
> >
> > --
> > Michael Mior
> > mm...@apache.org
> >
> >
> > Le jeu. 18 oct. 2018 à 15:37, Julian Hyde  a écrit :
> >
> > > I’m not too concerned about the "Do you aim to get an entry in
> > > accidentallyquadratic?” comment — it could be interpreted humorously,
> if
> > it
> > > were not at a end of a long, contentious review thread.
> > >
> > > I am more concerned that it was a long contentious review thread. The
> > > problem is that Vladimir is dogmatic. He makes a point, that point is
> > > acknowledged by the other party, but he absolutely refuses to give
> > ground.
> > > This occurs on the issue of messages for assert statements, and on the
> > > issue of the O(n ^ 2) performance of the algorithm.
> > >
> > > There is no path to consensus, other than yielding to Vladimir.
> > >
> > > I have experienced this behavior also. I had fixed a bug — the
> expression
> > > “TRUE IS FALSE” was being simplified to TRUE — and Vladimir vetoed my
> fix
> > > on the “technical grounds” that I had added tests without sufficient
> > error
> > > messages. The veto left me absolutely furious, and I seriously
> considered
> > > leaving the community. I surmise that other people who are on the
> > receiving
> > > end of his criticism may feel the same way.
> > >
> > > I appreciate Vladimir’s efforts reviewing code, and I appreciate his
> high
> > > standards, but he needs to change his communication style.
> > >
> > > Perhaps it would be useful if we discuss under what circumstances a
> > > committer can veto a change. ASF policy [1] says the following:
> > >
> > > > Votes on code modifications follow a different model. In
> > > > this scenario, a negative vote constitutes a veto, which
> > > > cannot be overridden.
> > >
> > > > If the R-T-C policy is in effect, a positive vote carries the
> > > > very strong implied message, 'I have tested this patch
> > > > myself, and found it good.' Similarly, a negative vote
> > > > usually means that the patch was tested and found to
> > > > be not -good, although the veto (for such it is in this
> > > > case) may be based on other technical grounds.
> > >
> > > I think we need to clarify what “technical grounds" means. Introducing
> a
> > > security hole would certainly qualify. As would introducing a bug in
> > > user-visible functionality (if the same change were not removing a more
> > > serious bug). But in less clear-cut cases, where the purported
> “technical
> > > grounds” are disputed or subjective, I think a consensus of other
> > > committers should override a veto.
> > >
> > > To be clear, the “technical grounds” veto is very important. But if the
> > > threat of it is preventing consensus building, we need to look at it
> > > carefully. Removing the veto threat forces reviewers build consensus,
> to
> > > persuade rather than cajole; it reduces the power of committers over
> > > non-committers, and encourages us to treat each other as equals.
> > >
> > > The commit veto is the “nuclear option” and I, for one, hope that it is
> > > never used again in this project.
> > >
> > > Julian
> > >
> > > [1] https://www.apache.org/foundation/voting.html <
> > > https://www.apache.org/foundation/voting.html>
> > >
> > >
> > >
> > > > On Oct 18, 2018, at 11:35 AM, Jesus Camacho Rodriguez <
> > > jcamachorodrig...@hortonworks.com> wrote:
> > > >
> > > > Is it OK for a PMC member of this community to engage with a new
> > > contributor to the project in this way?
> > > >
> > >
> >
> https://github.com/apache/calcite/commit/b470a0cd4572c9f6c4c0e9b51926b97c5af58d3f#r30950660
> > > >
> > > > I wanted to bring everyone´s attenti

Re: [DISCUSS] Where do we draw the line?

[Ashutosh Chauhan]

I have not contributed to Calcite in a while but I keep up with whats going
in project and actively follow mailing list and jiras of interest.
I concur with Josh that it is public shaming and bullying. This is not
acceptable. Also, this is not an exception but pattern which tells me that
it will continue in future too.
This is not in line with ASF code of conduct and respectful dialog expected
in community.

Thanks,
Ashutosh

On Thu, Oct 18, 2018 at 4:24 PM Michael Mior  wrote:

> You can see that I already responded to the comment and I don't really have
> many further thoughts. I do agree though that it's true that this could
> have been intended humorously and my reaction didn't acknowledge that. That
> said, it's of course worth considering with comments intended to be
> humorous how they will be perceived.
>
> --
> Michael Mior
> mm...@apache.org
>
>
> Le jeu. 18 oct. 2018 à 15:37, Julian Hyde  a écrit :
>
> > I’m not too concerned about the "Do you aim to get an entry in
> > accidentallyquadratic?” comment — it could be interpreted humorously, if
> it
> > were not at a end of a long, contentious review thread.
> >
> > I am more concerned that it was a long contentious review thread. The
> > problem is that Vladimir is dogmatic. He makes a point, that point is
> > acknowledged by the other party, but he absolutely refuses to give
> ground.
> > This occurs on the issue of messages for assert statements, and on the
> > issue of the O(n ^ 2) performance of the algorithm.
> >
> > There is no path to consensus, other than yielding to Vladimir.
> >
> > I have experienced this behavior also. I had fixed a bug — the expression
> > “TRUE IS FALSE” was being simplified to TRUE — and Vladimir vetoed my fix
> > on the “technical grounds” that I had added tests without sufficient
> error
> > messages. The veto left me absolutely furious, and I seriously considered
> > leaving the community. I surmise that other people who are on the
> receiving
> > end of his criticism may feel the same way.
> >
> > I appreciate Vladimir’s efforts reviewing code, and I appreciate his high
> > standards, but he needs to change his communication style.
> >
> > Perhaps it would be useful if we discuss under what circumstances a
> > committer can veto a change. ASF policy [1] says the following:
> >
> > > Votes on code modifications follow a different model. In
> > > this scenario, a negative vote constitutes a veto, which
> > > cannot be overridden.
> >
> > > If the R-T-C policy is in effect, a positive vote carries the
> > > very strong implied message, 'I have tested this patch
> > > myself, and found it good.' Similarly, a negative vote
> > > usually means that the patch was tested and found to
> > > be not -good, although the veto (for such it is in this
> > > case) may be based on other technical grounds.
> >
> > I think we need to clarify what “technical grounds" means. Introducing a
> > security hole would certainly qualify. As would introducing a bug in
> > user-visible functionality (if the same change were not removing a more
> > serious bug). But in less clear-cut cases, where the purported “technical
> > grounds” are disputed or subjective, I think a consensus of other
> > committers should override a veto.
> >
> > To be clear, the “technical grounds” veto is very important. But if the
> > threat of it is preventing consensus building, we need to look at it
> > carefully. Removing the veto threat forces reviewers build consensus, to
> > persuade rather than cajole; it reduces the power of committers over
> > non-committers, and encourages us to treat each other as equals.
> >
> > The commit veto is the “nuclear option” and I, for one, hope that it is
> > never used again in this project.
> >
> > Julian
> >
> > [1] https://www.apache.org/foundation/voting.html <
> > https://www.apache.org/foundation/voting.html>
> >
> >
> >
> > > On Oct 18, 2018, at 11:35 AM, Jesus Camacho Rodriguez <
> > jcamachorodrig...@hortonworks.com> wrote:
> > >
> > > Is it OK for a PMC member of this community to engage with a new
> > contributor to the project in this way?
> > >
> >
> https://github.com/apache/calcite/commit/b470a0cd4572c9f6c4c0e9b51926b97c5af58d3f#r30950660
> > >
> > > I wanted to bring everyone´s attention to the issue because I do not
> > believe this behavior contributes to the health of the project, welcoming
> > new contributions, etc. The same could have been said in a very different
> > way, and I do not think Zoltan was engaging disrespectfully.
> > >
> > > I am not sure whether I am overreacting, I would like to hear others
> > opinion. Does anyone else in the PMC find this disturbing? Does the ASF
> > provide clear guidelines about how members of a community should engage
> > with each other?
> > >
> > > Thanks,
> > > Jesús
> >
> >
>

Re: [DISCUSS] Where do we draw the line?

[Michael Mior]

You can see that I already responded to the comment and I don't really have
many further thoughts. I do agree though that it's true that this could
have been intended humorously and my reaction didn't acknowledge that. That
said, it's of course worth considering with comments intended to be
humorous how they will be perceived.

--
Michael Mior
mm...@apache.org


Le jeu. 18 oct. 2018 à 15:37, Julian Hyde  a écrit :

> I’m not too concerned about the "Do you aim to get an entry in
> accidentallyquadratic?” comment — it could be interpreted humorously, if it
> were not at a end of a long, contentious review thread.
>
> I am more concerned that it was a long contentious review thread. The
> problem is that Vladimir is dogmatic. He makes a point, that point is
> acknowledged by the other party, but he absolutely refuses to give ground.
> This occurs on the issue of messages for assert statements, and on the
> issue of the O(n ^ 2) performance of the algorithm.
>
> There is no path to consensus, other than yielding to Vladimir.
>
> I have experienced this behavior also. I had fixed a bug — the expression
> “TRUE IS FALSE” was being simplified to TRUE — and Vladimir vetoed my fix
> on the “technical grounds” that I had added tests without sufficient error
> messages. The veto left me absolutely furious, and I seriously considered
> leaving the community. I surmise that other people who are on the receiving
> end of his criticism may feel the same way.
>
> I appreciate Vladimir’s efforts reviewing code, and I appreciate his high
> standards, but he needs to change his communication style.
>
> Perhaps it would be useful if we discuss under what circumstances a
> committer can veto a change. ASF policy [1] says the following:
>
> > Votes on code modifications follow a different model. In
> > this scenario, a negative vote constitutes a veto, which
> > cannot be overridden.
>
> > If the R-T-C policy is in effect, a positive vote carries the
> > very strong implied message, 'I have tested this patch
> > myself, and found it good.' Similarly, a negative vote
> > usually means that the patch was tested and found to
> > be not -good, although the veto (for such it is in this
> > case) may be based on other technical grounds.
>
> I think we need to clarify what “technical grounds" means. Introducing a
> security hole would certainly qualify. As would introducing a bug in
> user-visible functionality (if the same change were not removing a more
> serious bug). But in less clear-cut cases, where the purported “technical
> grounds” are disputed or subjective, I think a consensus of other
> committers should override a veto.
>
> To be clear, the “technical grounds” veto is very important. But if the
> threat of it is preventing consensus building, we need to look at it
> carefully. Removing the veto threat forces reviewers build consensus, to
> persuade rather than cajole; it reduces the power of committers over
> non-committers, and encourages us to treat each other as equals.
>
> The commit veto is the “nuclear option” and I, for one, hope that it is
> never used again in this project.
>
> Julian
>
> [1] https://www.apache.org/foundation/voting.html <
> https://www.apache.org/foundation/voting.html>
>
>
>
> > On Oct 18, 2018, at 11:35 AM, Jesus Camacho Rodriguez <
> jcamachorodrig...@hortonworks.com> wrote:
> >
> > Is it OK for a PMC member of this community to engage with a new
> contributor to the project in this way?
> >
> https://github.com/apache/calcite/commit/b470a0cd4572c9f6c4c0e9b51926b97c5af58d3f#r30950660
> >
> > I wanted to bring everyone´s attention to the issue because I do not
> believe this behavior contributes to the health of the project, welcoming
> new contributions, etc. The same could have been said in a very different
> way, and I do not think Zoltan was engaging disrespectfully.
> >
> > I am not sure whether I am overreacting, I would like to hear others
> opinion. Does anyone else in the PMC find this disturbing? Does the ASF
> provide clear guidelines about how members of a community should engage
> with each other?
> >
> > Thanks,
> > Jesús
>
>

Re: Re: Exception-handling in built-in functions

[Stamatis Zampetakis]

Hello,

First of all, thanks Hongze for working on this!

CALCITE-525 asks for throwing exceptions in certain circumstances and I
think the fix should focus exclusively on this.

Regarding the discussion about additional actions in case of an error
(omitting rows or logging) I believe it is useful but I think it could be
achieved by other means such as overloading the operators (using
SqlOperatorTable). Omitting rows or logging is not a very common policy to
become part of the core project. I think that projects relying on Calcite
and need this kind of functionality could provide their own operator
overloads relatively easy.

Providing additional built in functions, such as CATCH_ERROR, might become
handy in some situations but again it is something that individual projects
could easily plugin as a user defined function.

Note that, I am not against the existing PR but I would like to highlight
an alternative option.

Best,
Stamatis

Στις Πέμ, 18 Οκτ 2018 στις 1:36 μ.μ., ο/η notify...@126.com <
notify...@126.com> έγραψε:

> Hi,
>
> Thanks for opening this discussion and thank you all for your replies.
>
> The reason why I would like to help solve CALCITE-525 is because I agree
> that an function error should not easily break a large job, this "job"
> could indicate a large ad-hoc query or a query on a stream, or like what
> Julian said, a ETL job.
> According to some tests I had run about Calcite streaming, a simple
> division by zero error could break the whole query job. Say, If Calcite
> does not provide a option to silence the error, users should spend extract
> daily time on checking whether their streaming job is alive if their SQL
> includes a "/" operator.
>
> The solutions of B and C are different: B is to ignore and drop a whole
> row when error happens, and C is to make the failed call return null value.
> In C, the major reason to introduce "CATCH_ERROR" function is to represent
> the error handling on Rel, whether to enable the function in Parser is not
> important.
> At first I personally prefer C, but as C does need more code change than
> B, I don't have a very strong inclination between B and C now.
>
> At last, I agree that making enough discussion on introducing new feature
> is very important. If we don't really need such a feature now, I think I
> can help whenever it is considered helpful in future.
>
> Thanks,
> Hongze
>
> From: Jesus Camacho Rodriguez
> Date: 2018-10-18 10:26
> To: dev@calcite.apache.org
> Subject: Re: Exception-handling in built-in functions
> I do not believe there is enough reason to block CALCITE-525. IMO,
> CALCITE-525 describes a problem that some Calcite users are facing and a
> reasonable plugable solution. We should not be vetoing such a feature
> without providing viable alternatives. (Without having checked the specific
> implementation details, I prefer approach B described below as it is less
> intrusive. And A should be fixed in a different issue.)
> I agree with Julian´s idea that Calcite is not a RDBMS such as Oracle or
> Postgres, and it has always tried to provide flexibility to underlying
> engines, one of the reasons for its wide adoption. In addition, systems are
> not forced to use this feature, it is tagged as experimental and by default
> we are still running in same mode. I believe that is sufficient.
> Personally, I will not be happy if a developer feels compelled to fork
> Calcite or stop contributing code because we do not accept features such as
> the one described there.
>
> Thanks,
> Jesús
>
>
> On 10/17/18, 5:17 PM, "Michael Mior"  wrote:
>
> My apologies for missing this thread a couple days ago. (Thanks for
> pinging
> it.) Here's my two cents: taking care of contributors to the project is
> just as important (if not more important) than taking care of the
> code. I'm
> not saying we should merge terrible code just to keep each other
> happy, but
> I don't think that's the case here. If anyone writes some code which
> you
> disagree with, you should be free to voice your disagreement. However,
> especially when the code is from a core contributor and the argument
> focuses on potential future problems, I think it's important to
> consider
> that people who have shown dedication to the project over the years are
> very likely to be around and willing to fix these problems as they
> arise.
>
> Code which turns out to cause problems can always be deleted, reverted,
> refactored, etc. It's much harder to back out when a contributor is
> burned
> out or interpersonal conflicts get heated.
>
> --
> Michael Mior
> mm...@apache.org
>
>
> Le mer. 17 oct. 2018 à 14:58, Julian Hyde  a écrit :
>
> > Vladimir,
> >
> > You’ve made your points. And I hear them.
> >
> > However I get the impression that you are not open to persuasion.
> Which
> > means that I am wasting my time trying to reach consensus with you.
> Which
> > means that people win argume

Re: [DISCUSS] Where do we draw the line?

[Josh Elser]

Let's not mince words about what this was: it was public shaming and 
bullying.


Looking at that thread you linked: Zoltan was trying to describe why he 
thought this was not a big problem. I can't say well enough whether he 
is right or not (that's beside the point). It was completely 
inappropriate for Vladimir to bully him. Furthermore, this seems to be 
completely one-sided (although, if it were two-sided, that doesn't 
justify either side in acting this way).


This kind of crap is against the ASF code of conduct[1], and, having 
watched multiple email threads call attention to similar situation, I'm 
starting to think that this is the "norm" and not the exception from 
Vladimir which the PMC should consider taking action to correct.


[1] https://www.apache.org/foundation/policies/conduct.html

On 10/18/18 2:35 PM, Jesus Camacho Rodriguez wrote:

Is it OK for a PMC member of this community to engage with a new contributor to 
the project in this way?
https://github.com/apache/calcite/commit/b470a0cd4572c9f6c4c0e9b51926b97c5af58d3f#r30950660

I wanted to bring everyone´s attention to the issue because I do not believe 
this behavior contributes to the health of the project, welcoming new 
contributions, etc. The same could have been said in a very different way, and 
I do not think Zoltan was engaging disrespectfully.

I am not sure whether I am overreacting, I would like to hear others opinion. 
Does anyone else in the PMC find this disturbing? Does the ASF provide clear 
guidelines about how members of a community should engage with each other?

Thanks,
Jesús

Re: [DISCUSS] Where do we draw the line?

[Julian Hyde]

I’m not too concerned about the "Do you aim to get an entry in 
accidentallyquadratic?” comment — it could be interpreted humorously, if it 
were not at a end of a long, contentious review thread.

I am more concerned that it was a long contentious review thread. The problem 
is that Vladimir is dogmatic. He makes a point, that point is acknowledged by 
the other party, but he absolutely refuses to give ground. This occurs on the 
issue of messages for assert statements, and on the issue of the O(n ^ 2) 
performance of the algorithm.

There is no path to consensus, other than yielding to Vladimir.

I have experienced this behavior also. I had fixed a bug — the expression “TRUE 
IS FALSE” was being simplified to TRUE — and Vladimir vetoed my fix on the 
“technical grounds” that I had added tests without sufficient error messages. 
The veto left me absolutely furious, and I seriously considered leaving the 
community. I surmise that other people who are on the receiving end of his 
criticism may feel the same way.

I appreciate Vladimir’s efforts reviewing code, and I appreciate his high 
standards, but he needs to change his communication style.

Perhaps it would be useful if we discuss under what circumstances a committer 
can veto a change. ASF policy [1] says the following:

> Votes on code modifications follow a different model. In
> this scenario, a negative vote constitutes a veto, which
> cannot be overridden.

> If the R-T-C policy is in effect, a positive vote carries the
> very strong implied message, 'I have tested this patch
> myself, and found it good.' Similarly, a negative vote
> usually means that the patch was tested and found to
> be not -good, although the veto (for such it is in this
> case) may be based on other technical grounds.

I think we need to clarify what “technical grounds" means. Introducing a 
security hole would certainly qualify. As would introducing a bug in 
user-visible functionality (if the same change were not removing a more serious 
bug). But in less clear-cut cases, where the purported “technical grounds” are 
disputed or subjective, I think a consensus of other committers should override 
a veto.

To be clear, the “technical grounds” veto is very important. But if the threat 
of it is preventing consensus building, we need to look at it carefully. 
Removing the veto threat forces reviewers build consensus, to persuade rather 
than cajole; it reduces the power of committers over non-committers, and 
encourages us to treat each other as equals.

The commit veto is the “nuclear option” and I, for one, hope that it is never 
used again in this project.

Julian

[1] https://www.apache.org/foundation/voting.html 




> On Oct 18, 2018, at 11:35 AM, Jesus Camacho Rodriguez 
>  wrote:
> 
> Is it OK for a PMC member of this community to engage with a new contributor 
> to the project in this way?
> https://github.com/apache/calcite/commit/b470a0cd4572c9f6c4c0e9b51926b97c5af58d3f#r30950660
> 
> I wanted to bring everyone´s attention to the issue because I do not believe 
> this behavior contributes to the health of the project, welcoming new 
> contributions, etc. The same could have been said in a very different way, 
> and I do not think Zoltan was engaging disrespectfully.
> 
> I am not sure whether I am overreacting, I would like to hear others opinion. 
> Does anyone else in the PMC find this disturbing? Does the ASF provide clear 
> guidelines about how members of a community should engage with each other?
> 
> Thanks,
> Jesús

[DISCUSS] Where do we draw the line?

[Jesus Camacho Rodriguez]

Is it OK for a PMC member of this community to engage with a new contributor to 
the project in this way?
https://github.com/apache/calcite/commit/b470a0cd4572c9f6c4c0e9b51926b97c5af58d3f#r30950660

I wanted to bring everyone´s attention to the issue because I do not believe 
this behavior contributes to the health of the project, welcoming new 
contributions, etc. The same could have been said in a very different way, and 
I do not think Zoltan was engaging disrespectfully.

I am not sure whether I am overreacting, I would like to hear others opinion. 
Does anyone else in the PMC find this disturbing? Does the ASF provide clear 
guidelines about how members of a community should engage with each other?

Thanks,
Jesús

Re: Re: Exception-handling in built-in functions

[张宏泽]

Hi,

Thanks for opening this discussion and thank you all for your replies.

The reason why I would like to help solve CALCITE-525 is because I agree that 
an function error should not easily break a large job, this "job" could 
indicate a large ad-hoc query or a query on a stream, or like what Julian said, 
a ETL job.
According to some tests I had run about Calcite streaming, a simple division by 
zero error could break the whole query job. Say, If Calcite does not provide a 
option to silence the error, users should spend extract daily time on checking 
whether their streaming job is alive if their SQL includes a "/" operator.

The solutions of B and C are different: B is to ignore and drop a whole row 
when error happens, and C is to make the failed call return null value. In C, 
the major reason to introduce "CATCH_ERROR" function is to represent the error 
handling on Rel, whether to enable the function in Parser is not important.
At first I personally prefer C, but as C does need more code change than B, I 
don't have a very strong inclination between B and C now.

At last, I agree that making enough discussion on introducing new feature is 
very important. If we don't really need such a feature now, I think I can help 
whenever it is considered helpful in future.

Thanks,
Hongze

notify...@126.com

From: Jesus Camacho Rodriguez
Date: 2018-10-18 10:26
To: dev@calcite.apache.org
Subject: Re: Exception-handling in built-in functions
I do not believe there is enough reason to block CALCITE-525. IMO, CALCITE-525 
describes a problem that some Calcite users are facing and a reasonable 
plugable solution. We should not be vetoing such a feature without providing 
viable alternatives. (Without having checked the specific implementation 
details, I prefer approach B described below as it is less intrusive. And A 
should be fixed in a different issue.)
I agree with Julian´s idea that Calcite is not a RDBMS such as Oracle or 
Postgres, and it has always tried to provide flexibility to underlying engines, 
one of the reasons for its wide adoption. In addition, systems are not forced 
to use this feature, it is tagged as experimental and by default we are still 
running in same mode. I believe that is sufficient.
Personally, I will not be happy if a developer feels compelled to fork Calcite 
or stop contributing code because we do not accept features such as the one 
described there.

Thanks,
Jesús


On 10/17/18, 5:17 PM, "Michael Mior"  wrote:

My apologies for missing this thread a couple days ago. (Thanks for pinging
it.) Here's my two cents: taking care of contributors to the project is
just as important (if not more important) than taking care of the code. I'm
not saying we should merge terrible code just to keep each other happy, but
I don't think that's the case here. If anyone writes some code which you
disagree with, you should be free to voice your disagreement. However,
especially when the code is from a core contributor and the argument
focuses on potential future problems, I think it's important to consider
that people who have shown dedication to the project over the years are
very likely to be around and willing to fix these problems as they arise.

Code which turns out to cause problems can always be deleted, reverted,
refactored, etc. It's much harder to back out when a contributor is burned
out or interpersonal conflicts get heated.

--
Michael Mior
mm...@apache.org


Le mer. 17 oct. 2018 à 14:58, Julian Hyde  a écrit :

> Vladimir,
>
> You’ve made your points. And I hear them.
>
> However I get the impression that you are not open to persuasion. Which
> means that I am wasting my time trying to reach consensus with you. Which
> means that people win arguments not on merit, but based upon who is most
> persistent.
>
> Here is my point. Calcite's goal is not to re-create what Oracle or
> PostgreSQL did ten years later. It is a platform that allows people to
> write their own data engine. If they want to redefine the “+” operator 
such
> that 2 + 2 returns 5, the platform should allow it.
>
> Certainly if they want to engineer their own error-handling strategy, we
> should let them do it. I didn’t have the energy to find an example of a 
SQL
> engine that discards rows with divide-by-zero errors, but I believe there
> is one. I suspect that both Broadbase, SQLstream and Hive, three SQL
> engines that I have worked on that performed ETL-like tasks, all had that
> capability. And all ETL tools have very flexible error-handling 
strategies.
> They are not SQL-based, but Calcite is not exclusively for SQL systems.
>
> I have been designing and building world-class data engines for 30 years.
> Please take me on good faith that a flexibl

[jira] [Created] (CALCITE-2632) Add hashCode and equals implementations to RexNode

[Zoltan Haindrich (JIRA)]

Zoltan Haindrich created CALCITE-2632:
-

 Summary: Add hashCode and equals implementations to RexNode 
 Key: CALCITE-2632
 URL: https://issues.apache.org/jira/browse/CALCITE-2632
 Project: Calcite
  Issue Type: Bug
Reporter: Zoltan Haindrich
Assignee: Zoltan Haindrich


Right now RexNode doesn't have any equals or hashCode functions; which makes it 
rely on the default implementation.

But when we are writing simplification logics we sometimes forget to use 
{{toString()}} during comparisions and may try to rely on pure equals:

* there is a [Set of 
RexNode-s|https://github.com/apache/calcite/blob/5b16e23dff03e5eaed80642ae91e28ebf806e6b0/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L1104]
 during {{AND}} simplification and in [RexUtil as 
well|https://github.com/apache/calcite/blob/5b16e23dff03e5eaed80642ae91e28ebf806e6b0/core/src/main/java/org/apache/calcite/rex/RexUtil.java#L321]
* I've by mistake just written rexNode.equals(otherRexNode) during the 
implementation of CALCITE-1413
* I've just bumped into the same thing...that 
[RexUtil.andNot|https://github.com/apache/calcite/blob/5b16e23dff03e5eaed80642ae91e28ebf806e6b0/core/src/main/java/org/apache/calcite/rex/RexUtil.java#L1888]
 is also rely on itand I think those comparisions go back a while (~3years 
at least) ; and a bug is not appeared from it because this comparision is in 
most cases false.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Re: Exception-handling in built-in functions

[notify...@126.com]

Hi,

Thanks for opening this discussion and thank you all for your replies.

The reason why I would like to help solve CALCITE-525 is because I agree that 
an function error should not easily break a large job, this "job" could 
indicate a large ad-hoc query or a query on a stream, or like what Julian said, 
a ETL job.
According to some tests I had run about Calcite streaming, a simple division by 
zero error could break the whole query job. Say, If Calcite does not provide a 
option to silence the error, users should spend extract daily time on checking 
whether their streaming job is alive if their SQL includes a "/" operator.

The solutions of B and C are different: B is to ignore and drop a whole row 
when error happens, and C is to make the failed call return null value. In C, 
the major reason to introduce "CATCH_ERROR" function is to represent the error 
handling on Rel, whether to enable the function in Parser is not important.
At first I personally prefer C, but as C does need more code change than B, I 
don't have a very strong inclination between B and C now.

At last, I agree that making enough discussion on introducing new feature is 
very important. If we don't really need such a feature now, I think I can help 
whenever it is considered helpful in future.

Thanks,
Hongze
 
From: Jesus Camacho Rodriguez
Date: 2018-10-18 10:26
To: dev@calcite.apache.org
Subject: Re: Exception-handling in built-in functions
I do not believe there is enough reason to block CALCITE-525. IMO, CALCITE-525 
describes a problem that some Calcite users are facing and a reasonable 
plugable solution. We should not be vetoing such a feature without providing 
viable alternatives. (Without having checked the specific implementation 
details, I prefer approach B described below as it is less intrusive. And A 
should be fixed in a different issue.)
I agree with Julian´s idea that Calcite is not a RDBMS such as Oracle or 
Postgres, and it has always tried to provide flexibility to underlying engines, 
one of the reasons for its wide adoption. In addition, systems are not forced 
to use this feature, it is tagged as experimental and by default we are still 
running in same mode. I believe that is sufficient.
Personally, I will not be happy if a developer feels compelled to fork Calcite 
or stop contributing code because we do not accept features such as the one 
described there.
 
Thanks,
Jesús
 
 
On 10/17/18, 5:17 PM, "Michael Mior"  wrote:
 
My apologies for missing this thread a couple days ago. (Thanks for pinging
it.) Here's my two cents: taking care of contributors to the project is
just as important (if not more important) than taking care of the code. I'm
not saying we should merge terrible code just to keep each other happy, but
I don't think that's the case here. If anyone writes some code which you
disagree with, you should be free to voice your disagreement. However,
especially when the code is from a core contributor and the argument
focuses on potential future problems, I think it's important to consider
that people who have shown dedication to the project over the years are
very likely to be around and willing to fix these problems as they arise.

Code which turns out to cause problems can always be deleted, reverted,
refactored, etc. It's much harder to back out when a contributor is burned
out or interpersonal conflicts get heated.

--
Michael Mior
mm...@apache.org


Le mer. 17 oct. 2018 à 14:58, Julian Hyde  a écrit :

> Vladimir,
>
> You’ve made your points. And I hear them.
>
> However I get the impression that you are not open to persuasion. Which
> means that I am wasting my time trying to reach consensus with you. Which
> means that people win arguments not on merit, but based upon who is most
> persistent.
>
> Here is my point. Calcite's goal is not to re-create what Oracle or
> PostgreSQL did ten years later. It is a platform that allows people to
> write their own data engine. If they want to redefine the “+” operator 
such
> that 2 + 2 returns 5, the platform should allow it.
>
> Certainly if they want to engineer their own error-handling strategy, we
> should let them do it. I didn’t have the energy to find an example of a 
SQL
> engine that discards rows with divide-by-zero errors, but I believe there
> is one. I suspect that both Broadbase, SQLstream and Hive, three SQL
> engines that I have worked on that performed ETL-like tasks, all had that
> capability. And all ETL tools have very flexible error-handling 
strategies.
> They are not SQL-based, but Calcite is not exclusively for SQL systems.
>
> I have been designing and building world-class data engines for 30 years.
> Please take me on good faith that a flexible error-handing strategy is a
> good idea. Don’t force me to bicker over email for hours and ho