virajjasani commented on PR #1724:
URL: https://github.com/apache/phoenix/pull/1724#issuecomment-1783362587
> @virajjasani Thinking what changed from this PR #1697 ?
this is the main diff:
```
public static void verifyKeyInScanRange(ImmutableBytesWritable ptr,
Scan scan,
Tuple tuple)
throws ResultSetOutOfScanRangeException {
if ((tuple.size() == 1 && tuple.getValue(SINGLE_COLUMN_FAMILY,
SINGLE_COLUMN) != null)
|| (tuple.size() == 1 && tuple.getValue(OFFSET_FAMILY,
OFFSET_COLUMN) != null)
|| isDummy(tuple)) {
return;
}
if (isLocalIndex(scan)) {
verifyScanRanges(ptr, scan,
scan.getAttribute(SCAN_START_ROW_SUFFIX),
scan.getAttribute(SCAN_STOP_ROW_SUFFIX));
} else {
try {
verifyScanRanges(ptr, scan, scan.getStartRow(),
scan.getStopRow());
} catch (ResultSetOutOfScanRangeException e) {
// required for Salt Buckets scan boundary changes
verifyScanRanges(ptr, scan,
scan.getAttribute(SCAN_ACTUAL_START_ROW),
scan.getStopRow());
}
}
}
```
Basically, we need to take care of these cases:
- Aggregate scan results
- Offset based results
- Dummy cell
- Local index scan boundary changes
- Salt table scan boundary changes
But anyways, fixing group by aggregator cases is required at server side for
data integrity issues. I just wanted to exercise on how many cases we need to
handle here. I am sure local index and salt table scan boundary changes might
also need some careful considerations at server side.
FYI @Divneet18, you can incorporate the changes and write a test with coproc
that can return incorrect result so that we can test scan boundaries negative
results.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
