-
Notifications
You must be signed in to change notification settings - Fork 322
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
fix: batch: compile warning that check a long for null #1408 #1870
Conversation
There are some test failures. Please make sure you can run tests in local @Ivyee17 . |
May be I will try it once the issue is assigned to me. I misunderstand that this issue has already assigned to me. 😂 |
hi @Ivyee17 the issue have been assigned to you. |
Codecov Report
@@ Coverage Diff @@
## main #1870 +/- ##
============================================
+ Coverage 75.69% 75.72% +0.02%
Complexity 347 347
============================================
Files 613 613
Lines 117059 117059
Branches 1024 1008 -16
============================================
+ Hits 88613 88640 +27
+ Misses 28237 28210 -27
Partials 209 209
Continue to review full report at Codecov.
|
It has been correct now. @dl239 |
If there is any question about this issue, feel free to contact me. @vagetablechicken @tobegit3hub |
@@ -730,7 +730,7 @@ object WindowAggPlan { | |||
|
|||
|
|||
|
|||
def isValidOrder(key: Long): Boolean = { | |||
def isValidOrder(key: java.lang.Long): Boolean = { |
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.
isValidOrder
always check the orderKey from val orderKey = computer.extractKey(row)
.
But extractKey
returns scala Long, you should make it return java Long too.
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.
There are some test failures. Please make sure you can run tests in local @Ivyee17 .
I've already made changes in the previous PR, it will cause test failures, as @dl239 said before. @vagetablechicken
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.
The failure is about delete-extract-key, if changing it to java.lang.Lang too, then this test will fail. Searching a key which is deleted before will be true, not false. I wonder if there's mistakes in extractKey
function. Besides, I do think it's far beyond what should be done in this PR. I just need to resolve the warning log, not the complete process, right? Another issue and pr should be taken instead of this issue!!
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.
LGTM
After check, the pr should only fix |
close #1408