Fix table.Smallest/Biggest and iterator Prefix bug #997
Conversation
The pick table compares the smallest and biggest key of each table against the iteratorOptions.Prefix. The smallest and biggest key contain timestamps while the prefix does not contains timestamp. So pickTable would return not return the correct tables. For example Table has Smallest [0 255 255... ] and prefix [0, 0, 1], the comparison of these two values would return true implying that the smallest is greater than the prefix which is incorrect because prefix doesn't contains a timestamp and smallest does. With this commit, we compare the smallest/biggest keys without timestamps to the opt.Prefix. See #992 for more details.
jarifibrahim
requested review from
ashish-goswami and
manishrjain
as code owners
![pullrequest[bot]](https://avatars.githubusercontent.com/in/3434?s=60&v=4){kind=small}
There was a problem hiding this comment.
✅ A review job has been created and sent to the PullRequest network.
@jarifibrahim you can click here to see the review status or cancel the code review job.
|
Just fixed this in #983 |
|
Just check why travis is failing for Go1.11. |
manishrjain
left a comment
manishrjain
left a comment
There was a problem hiding this comment.
Reviewable status: 0 of 4 files reviewed, all discussions resolved (waiting on @manishrjain)
There was a problem hiding this comment.
Thank you for updating the comment and finding this bug. I have no additional feedback for this PR.
Reviewed with ❤️ by PullRequest
|
@manishrjain Added a regression test. |
The test for checksum mismatch was failing but I reran and it passed. Looks like we have a flaky test. |
The pick table compares the smallest and biggest key of each table against the iteratorOptions.Prefix. The smallest and biggest key contain timestamps while the prefix does not contains timestamp. So pickTable would not return the correct tables. For example Table has Smallest [0 255 255... ] and prefix [0, 0, 1], the comparison of these two values would return true implying that the smallest is greater than the prefix which is incorrect because prefix doesn't contains a timestamp and smallest does. With this commit, we compare the smallest/biggest keys without timestamps to the opt.Prefix. See #992 for more details. (cherry picked from commit 5f64ecf)
The pick table compares the smallest and biggest key of each table
against the iteratorOptions.Prefix. The smallest and biggest key contain
timestamps while the prefix does not contain a timestamp. So pickTable
would return not return the correct tables.
For example
Table has Smallest [0 255 255... ] and prefix [0, 0, 1], the comparison
of these two values would return true implying that the smallest is
greater than the prefix which is incorrect because prefix doesn't
contains a timestamp and smallest does.
With this commit, we compare the smallest/biggest keys without
timestamps to the opt.Prefix.
Fixes #992
This change is