Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 09E2B200C13 for ; Mon, 6 Feb 2017 10:12:46 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 0874A160B53; Mon, 6 Feb 2017 09:12:46 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 53921160B49 for ; Mon, 6 Feb 2017 10:12:45 +0100 (CET) Received: (qmail 48945 invoked by uid 500); 6 Feb 2017 09:12:44 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 48934 invoked by uid 99); 6 Feb 2017 09:12:44 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Feb 2017 09:12:44 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id EF016C12C0 for ; Mon, 6 Feb 2017 09:12:43 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_LAZY_DOMAIN_SECURITY=1, RP_MATCHES_RCVD=-2.999] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id ucQ3T4PKQ3ol for ; Mon, 6 Feb 2017 09:12:43 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 1ECBB5F5C7 for ; Mon, 6 Feb 2017 09:12:43 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 6890DE030A for ; Mon, 6 Feb 2017 09:12:42 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id D47812528E for ; Mon, 6 Feb 2017 09:12:41 +0000 (UTC) Date: Mon, 6 Feb 2017 09:12:41 +0000 (UTC) From: "Phil Yang (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-17599) Also set the partial flag of Result to true if we reach the batch limit MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Mon, 06 Feb 2017 09:12:46 -0000 [ https://issues.apache.org/jira/browse/HBASE-17599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15853727#comment-15853727 ] Phil Yang commented on HBASE-17599: ----------------------------------- Do we want to set flag in proto of response only, or expose to users' Result.isPartial()? HBASE-15484 wants to change the semantic users' Result.isPartial(), without that patch, they are same. But it will reorg cells if user setBatch but don't allow partial, so the returned Result may be not same as responded from server. I think users need be able to know if the Result is exactly the last Result of this row or not, but now when users setBatch(5) and Result.size()==5, they can not know if it is the last one or this row. So we may change the meaning of isPartial or create a new api? > Also set the partial flag of Result to true if we reach the batch limit > ----------------------------------------------------------------------- > > 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 > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-17599.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)