refactor: refactor getRange operation using scanner#154
refactor: refactor getRange operation using scanner#154foreverneverer wants to merge 20 commits intoXiaoMi:masterfrom
Conversation
| this.exception = exception; | ||
| } | ||
|
|
||
| public MultiGetResult convertMultiGetResult() { |
There was a problem hiding this comment.
add comment for these two functions
| } | ||
| sortKeysResult.allFetched = result.allFetched; | ||
| return sortKeysResult; | ||
| ScanOptions scanOptions = new ScanOptions(); |
There was a problem hiding this comment.
should we reserver the old interface and add a new interface for these code?
There was a problem hiding this comment.
Actually, if like multiGet, origin multiGetSortKeys should also be retained and only marked Deprecated. but the API has been refactored by scan in previous PR and some user has use it, here I just keep it. @neverchanje @hycdong can give some suggestion
There was a problem hiding this comment.
I think it is okay to update code in function multiGetSortKeys, because it is already implemented by scan.
| Assertions.assertEquals("persistent_" + i, new String(caseD1.keys.get(i))); | ||
| Assertions.assertEquals("persistent_" + i, new String(result1.keys.get(i))); | ||
| } | ||
| // case D1: maxFetchCount < 0, return all valid record |
There was a problem hiding this comment.
case A,B,C have been moved to TestRange.java, how about update comment for case D1?
No description provided.