EungsopYoo commented on PR #6557:
URL: https://github.com/apache/hbase/pull/6557#issuecomment-2597470505
> ```
> if (PrivateCellUtil.isDelete(typeByte)) {
> boolean includeDeleteMarker =
> seePastDeleteMarkers ? tr.withinTimeRange(timestamp) :
tr.withinOrAfterTimeRange(timestamp);
> if (includeDeleteMarker) {
> this.deletes.add(cell);
> }
> return MatchCode.SKIP;
> }
> ```
>
> Seems incorrect, we will always return MatchCode.SKIP if we get a delete
maker...
>
> I think why we do not find this before is that, usually there will be only
one delete maker, so when we check the next cell, we will fall through and call
the checkDeleted method so we will seek to next row or column.
>
> Here the scenario is that we have bunch of delete makrer, then here we
will see them all instead of seek to next row or column, since we will always
go into the code block above and return MatchCode.SKIP.
>
> I think we should try to optimize the logic of the above code block.
https://github.com/apache/hbase/pull/6557/commits/f6739e2e2c45513f496211fc494faed722b4d80e
I removed the early `return MatchCode.SKIP` statement. But some test cases
related to NewVersionBehavior were failed after that.
https://github.com/apache/hbase/pull/6557/commits/74ecf712add5720deb6a3ebdfed9fa1ab8847dc7
So I restored `return MatchCode.SKIP` with some exceptional conditions.
--
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]
