[ 
https://issues.apache.org/jira/browse/HBASE-17599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang updated HBASE-17599:
------------------------------
    Release Note: The word 'isPartial' is ambiguous so we introduce a new 
method 'mayHaveMoreCellsInRow' to replace it. And the old meaning of 
'isPartial' is not the same with 'mayHaveMoreCellsInRow' as for batched scan, 
if the number of returned cells equals to the batch, isPartial will be false. 
After this change the meaning of 'isPartial' will be same with 
'mayHaveMoreCellsInRow'. This is an incompatible change but it is not likely to 
break a lot of things as for batched scan the old 'isPartial' is just a 
redundant information, i.e, if the number of returned cells reaches the batch 
limit. You have already know the number of returned cells and the value of 
batch.

> 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-branch-1.patch, HBASE-17599.patch, 
> HBASE-17599-v1.patch, HBASE-17599-v2.patch, HBASE-17599-v3.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 may 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)

Reply via email to