New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CALCITE-4368] TopDownOptTest fails if applying non-substitution rule first #2237
Conversation
d4de7a5
to
87868f4
Compare
Remember to update the commit message before commit. |
87868f4
to
392623d
Compare
Could you please tell me what I should update about the commit message? Thanks. |
392623d
to
f25bbc8
Compare
Updated the commit message. Thank you for your suggestion, @danny0405 . |
Frankly speaking, it is hard to review the change because there are lots of comment changes, and it is hard to spot code changes. Please refrain from mixing unrelated comment changes and code changes into a single commit. It does not mean I require that for this case, however, I opened this PR several times, and every time I thought it was javadoc-only change. |
@chunweilei , could you please clarify what is the nature of the change? The commit message says In case the PR is cosmetic, then the very same thing should be mentioned in the commit message. Otherwise, it is misleading, and it is time-consuming for the reviewers. |
@vlsi I have updated the commit message. This change not only fixes a bug but also have some fix-ups. |
core/src/main/java/org/apache/calcite/plan/volcano/TopDownRuleDriver.java
Show resolved
Hide resolved
I don't want to see many commits that only have comment changes. It is not necessary. But I should have underlined the main change. Then it is much easier for reviewers. |
@chunweilei, please split the change in two:
Currently, it is hard to figure out where is the code part of the change. |
Please add tests to cover the change |
It's difficult to add a test to reproduce it. But you can reproduce it if you change the applying order of substitution rule and non-substitution rule. I described it in the jira case. |
It must come as its own commit. You should not require each and every reviewer to inspect the diff in order to find a single line change buried under lots of comment changes. |
I do not require anything from anybody. It's just about preference. Does it really so difficult that someone has to spend hours on finding the main change? I don't think so. As you can see, two people have reviewed it at least and give their comments. |
I am open to this change. Would split the change into two soon. |
f25bbc8
to
b0d2f5a
Compare
… first Usually O_INPUTS are only applied for groups with physical convention. But when enabling AbstractConverter, the input of AbstractConverter might be a group with NONE convention. In that case, no need to apply O_INPUTS. Otherwise, it might throw en exception due to impossible transformation( physical convention -> none convention).
b0d2f5a
to
54b8d9d
Compare
I have split the change into two. Thank you for your suggestion. |
@@ -335,6 +336,14 @@ default boolean onProduce(RelNode node) { | |||
physicals.add(rel); | |||
} | |||
} | |||
|
|||
// No need to apply O_INPUTS if the group has not been implemented yet. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is O_INPUTS
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It means OptimzeInput, which is a term in Cascades planner. I borrow it from the comment[1].
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see no reasons to invent obscure words when the thing can be explained in plain English.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would change it as you suggest. But the term O_INPUT is not invented currently. It comes from a classic paper[1] which was published in 1998.
[1] https://15721.courses.cs.cmu.edu/spring2019/papers/22-optimizer1/xu-columbia-thesis1998.pdf Page#63
Thanks. It would be better if you specify the nature and the location of the change instead of the current
If the bug happens only if you manually edit Calcite source, then why do you think it is a bug after all?
I do not see where CALCITE-4368 describes why test can't be added. |
|
I mean I describe the way that reproduces the error in the JIRA case. |
I'm inclined that this change must be accompanied by a test, otherwise, it should not be committed. |
As you insist, I would try my best to provide one. |
Opened another PR to fix comments: #2243. |
Close the PR since I can not reproduce it without changes. |
Usually O_INPUTS are only applied for groups with physical convention. But
when enabling AbstractConverter, the input of AbstractConverter might be
a group with NONE convention. In that case, no need to apply O_INPUTS.
Otherwise, it might throw an exception due to impossible transformation(
physical convention -> none convention).
Other change: