Julian>And I would love a SQL test case that shows that SEARCH is broken. :)
I give you 100 char SQL reproducer and you restore pull/2250.
Deal?
Julian>But it is good news for people using Calcite 1.26 - it is very
Julian>unlikely that they are being affected by the bug.
Calcite 1.26 is
Pushing release 1.27 back to the New Year makes sense.
We need to do some work on Sargs. As to what that work should be,
things are going to get controversial. (I would appreciate help from
impartial elders like Stamatis, Francis, Haisheng to guide this
discussion to where we can agree.)
I agree
We currently maintain a release cadence of a new release every two
months. This puts the next release pretty close to Christmas next month.
Would it make sense if we push 1.27.0 back a few weeks until maybe after
new year? In the mean time, perhaps we can focus on getting these issues
fixed
And yet more passive-aggressive bulls**t from Vladimir:
https://github.com/apache/calcite/commit/c6b3fb7ddbf8aed981ff3fb0632c77216dbe68d6
I've force-pushed to remove it.
I plan to respond to Stamatis' thoughtful email later today. Also, I
think I may have a test case that demonstrates the
Stamatis>@Vladimir: Can you specify which JIRA issue(s) you would like to
see solved
Stamatis>for the next release?
RexProgramFuzzyTest should be enabled, and Sarg-related fuzzing should be
implemented as well.
RexFuzzer should generate Sarg expressions.
RexInterpreter should be able to evaluate
Stamatis,
Il Lun 16 Nov 2020, 10:20 Stamatis Zampetakis ha
scritto:
> Hello,
>
> I don't want the current situation to be disheartening for anybody,
> especially those who spend significant time on these code changes (Julian,
> Vladimir).
> Our common goal is to release 1.27.0 in the best
Hello,
I don't want the current situation to be disheartening for anybody,
especially those who spend significant time on these code changes (Julian,
Vladimir).
Our common goal is to release 1.27.0 in the best possible conditions so
let's try to agree on the plan to move forward.
To do this, I
Vladimir,
I’ve reverted your revert. A commit war is no way to proceed.
Julian
> On Nov 14, 2020, at 2:55 AM, Vladimir Sitnikov
> wrote:
>
> I've reverted SEARCH. Sorry for the inconvenience.
>
> Here's the PR that re-adds SEARCH:
> https://github.com/apache/calcite/pull/2263
> Please
I've reverted SEARCH. Sorry for the inconvenience.
Here's the PR that re-adds SEARCH:
https://github.com/apache/calcite/pull/2263
Please feel free to pick it up. I expect certain commits should be squashed
(e.g. search should be re-added as a single commit).
I'm not sure I would have time to
Julian>Removing it at this point would be disruptive
The sooner the revert the less the disruption is.
Julian>Let’s log bugs so that they can make an informed decision
It would be awesome if somebody picks up the task.
I've spent the past weekend resolving the issue thanks to the SEARCH PR
I have not spoken up because others have expressed my thoughts. Namely:
1. While there are problems with Search/Sarg it is a net benefit. Removing it
at this point would be disruptive.
2. Everyone except Vladimir opposes committing Vladimir’s PR to revert the
change.
3. It would be helpful if
Ruben>if they are not solved by then, then revert
The revert would be hard if we delay it :(
For instance, CALCITE-4383 and CALCITE-4389 do not seem to be related to
SEARCH, however, they touch the same files.
Vladimir
I share the concerns raised by Stamatis and Haisheng.
I understand the motivations behind Vladimir's decision, I would not oppose
a revert but I'm not 100% sure at this point it is the best approach.
I would lean towards creating bug tickets in Jira describing the known
issues, with version "1.27"
I see there is a desire to keep SEARCH in the next release.
I see there's a silence as well (e.g. some committers/PMCs are not
replying) which is understandable.
However, there's even more: Danny and Julian commit more changes/features
to search/sarg feature.
I guess it was unintentional,
Danny>We all vote -1 and what's the problem there you still want to revert ?
Danny, I see only you mention "-1", however, I see no technical reasons, so
I assume the veto has no weight.
I see the general feeling is like "oh, we want to keep the SEARCH feature
in the subsequent release" (which is
Stop the merge, PLEASE !!!
We all vote -1 and what's the problem there you still want to revert ?
What's the bug/problem there that need to be fixed? Can you log some issues
there ?
If the RexProgramFuzzyTest can not run, just fix it. From my local test, it
is not caused by the Sarg itself, it
Ok, it took me even more time to stabilize the build than I initially
expected as there were 4 misbehaving issues (4388, 4397, 4398, 4399)
The PR that reverts SEARCH is https://github.com/apache/calcite/pull/2250
I'll let the dust settle, and I merge it.
Hopefully, SEARCH then could be re-added
I have the same feeling with Stamatis.
I completely understand that Vladimir is trying to keep it working correctly.
However, I know some downstream project already updated Calcite version and
changed their code to adapt to the Sarg/SEARCH operator. Reverting it and in
case we failed to fix
Danny>-1 for the revert, we should fix the issues we encountered instead of
Danny>reverting the code brainless for a whole release.
Hi Danny, did you just veto the code change? (see
https://www.apache.org/foundation/voting.html#Veto )
I am afraid I fail to find a technical justification behind
-1 for the revert, we should fix the issues we encountered instead of
reverting the code brainless for a whole release.
At lease, project like Apache Flink has upgrade to version 1.26 and the
Sarg feature overall looks good.
We are trying to fix the Sarg issues in version 1.27 and we should
Stamatis>People who are responsible for upgrading Calcite, tend to follow
the dev
Stamatis>list so they can take the necessary actions.
I think behind the lines of updating https://calcite.apache.org/news/
We might want to mention the following regressions, and we might want to
mark the release
Thanks for raising awareness Vladimir.
To be honest, I am not sure how we should move forward but I think it's a
bit late to ask people not to upgrade.
We can let people know about the potential issues but I guess this is
already done via this mail.
People who are responsible for upgrading
I've created https://github.com/apache/calcite/pull/2250 to check if revert
helps at all.
Vladimir
Everybody,
I suggest we revert Sarg, and merge it back when it is ready (passes tests).
If no objections, I would proceed with reverting Sarg in 72 hours.
I believe we should announce that Calcite 1.26 has severe issues with
SEARCH,
and people should refrain from using the version. They might
It's going to be difficult to find time to do this. I would appreciate
some help.
Julian
On Sun, Nov 1, 2020 at 11:46 PM Vladimir Sitnikov
wrote:
>
> Hey Julian, thank you for rolling search/sarg expression. I believe it is a
> valuable feature.
>
> Unfortunately, the new feature causes
Hey Julian, thank you for rolling search/sarg expression. I believe it is a
valuable feature.
Unfortunately, the new feature causes noticeable regressions, and it looks
like the regressions are still there :(
I believe the major cause of regressions is missing tests for the added
feature :(
26 matches
Mail list logo
