[
https://issues.apache.org/jira/browse/HBASE-17599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15855124#comment-15855124
]
stack commented on HBASE-17599:
-------------------------------
It looks great.
Good doc on mayHaveMoreCellsInRow
bq. 913 * Deprecated since 1.4.0, will be removed in 2.0.0.
This is ambitious. It is ok if it sticks around longer than 2.0... 3.0?
bq. The client
927 * side implementation should also check for row key change to
determine if a Result is the last
928 * one for a row.
This is a little unsettling. Do we have to say this in the public API?
Do you want to change the ScannerContext method partialResultFormed to match
the above?
LGTM.
> Use mayHaveMoreCellsInRow instead of isPartial
> ----------------------------------------------
>
> Key: HBASE-17599
> URL: https://issues.apache.org/jira/browse/HBASE-17599
> Project: HBase
> Issue Type: Sub-task
> Components: Client, scan
> Affects Versions: 2.0.0, 1.4.0
> Reporter: Duo Zhang
> Assignee: Duo Zhang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17599.patch, HBASE-17599-v1.patch
>
>
> For now if we set scan.allowPartial(true), the partial result returned will
> have the partial flag set to true. But for scan.setBatch(xx), the partial
> result returned will not be marked as partial.
> This is an Incompatible change, indeed. But I do not think it will introduce
> any issues as we just provide more informations to client. The old partial
> flag for batched scan is always false so I do not think anyone can make use
> of it.
> This is very important for the limited scan to support partial results from
> server. If we get a Result which partial flag is false then we know we get
> the whole row. Otherwise we need to fetch one more row to see if the row key
> is changed which causes the logic to be more complicated.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
