-
Notifications
You must be signed in to change notification settings - Fork 339
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
CDAP-8745 Fix search total #8158
Conversation
@@ -608,7 +608,7 @@ private SearchResults searchByCustomIndex(String namespaceId, Set<EntityTypeSimp | |||
String indexColumn = getIndexColumn(sortInfo.getSortBy(), sortInfo.getSortOrder()); | |||
// we want to return the first chunk of 'limit' elements after offset | |||
// in addition, we want to pre-fetch 'numCursors' chunks of size 'limit' | |||
int fetchSize = offset + ((numCursors + 1) * limit); | |||
int fetchSize = (int) Math.min(offset + ((numCursors + 1) * (long) limit), Integer.MAX_VALUE); |
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.
why do we need all this casting?
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.
for when offset
is really large (larger than Integer.MAX_VALUE
?
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.
this seems wrong. just int fetchSize = offset + ((numCursors + 1) * limit);
should work?
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's possible for limit to be the Integer.MAX_VALUE
. If that's the case, then this line won't run properly.
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.
ok. Is this easier to read then?
if (Integer.MAX_VALUE == limit) {
fetchSize = limit;
} else {
fetchSize = offset + ((numCursors + 1) * limit);
}
It's ok to keep it the way it is, but please add a comment explaining why this is done.
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.
Well, in the off chance that limit
is very large, it would still not work for the code above. I'll add a comment documenting it, though.
@@ -1137,42 +1137,34 @@ public void apply() throws Exception { | |||
searchResults = dataset.search(namespaceId, "*", targets, nameAsc, 0, 2, 0, null, false, | |||
EnumSet.allOf(EntityScope.class)); | |||
Assert.assertEquals(ImmutableList.of(flowEntry, dsEntry), searchResults.getResults()); | |||
Assert.assertEquals(ImmutableList.of(flowEntry, dsEntry, appEntry), searchResults.getAllResults()); |
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 searchResults.getAllResults()
and why is it needed?
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.
getAllResults()
should get all search results, including the ones in the offset. This way, we'll be able to count the total.
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.
you mean if offset = 2, limit = 2, numCursors = 2
results will have (limit + 1) * numCursors = 6 elements, but all results will have offset + results = 8 elements?
To count the total, you don't actually need to return the results, right? You can just add the offset?
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.
If we do that, then we reintroduce the bug that was fixed in the last PR: https://issues.cask.co/browse/CDAP-7930.
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.
@Denton-L, a couple of comments. However, is there a test that covers this scenario somewhere? Would be good to ensure that there's a test which makes sure that a full scan is not done when not required.
@Denton-L I meant a test that does the following:
|
@bdmogal, in the unit tests, I introduced a check for |
@Denton-L ok. final comment: |
Yeah, good idea, I'll change the naming. And unfortunately, I've only tested this locally using |
Ok. I'd recommend pushing this to a cluster, and having @tonybach verify the fix as well, since it is so late in the release cycle :-) |
This commit fixes the bug where the total returned is incorrect when doing a sorted metadata search. Prior to this, the total returned was the actual total. Now, the total returned may be less than the actual total but the search is more efficient.
e3a6b86
to
4845d65
Compare
This commit fixes the bug where the total returned is incorrect when
doing a sorted metadata search. Prior to this, the total returned was
the actual total. Now, the total returned may be less than the actual
total but the search is more efficient.
JIRA: https://issues.cask.co/browse/CDAP-8745
Bamboo: http://builds.cask.co/browse/CDAP-RUT701