Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 17 Dec 2016 01:44:58 +0000 (UTC)
From: "Enis Soztutar (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13027023.1481298524000.544220.1481939098487@Atlassian.JIRA>
In-Reply-To: <JIRA.13027023.1481298524000@Atlassian.JIRA>
References: <JIRA.13027023.1481298524000@Atlassian.JIRA> <JIRA.13027023.1481298524453@arcas>
Subject: [jira] [Commented] (HBASE-17283) [C++] Result and ResultScanner
 classes
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sat, 17 Dec 2016 01:45:00 -0000


    [ https://issues.apache.org/jira/browse/HBASE-17283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15756040#comment-15756040 ] 

Enis Soztutar commented on HBASE-17283:
---------------------------------------

Sudeep, i had some free cycles, so I did some changes to your patch while reviewing. Hope you don't mind. 
- Rebased 
- Remove empty and readonly attributes from Result. empty is not needed since it is dynamically computable. readonly is an artifact from MR in the Java code base. No need in C++ client. 
- Added Row() method

A couple of comments that I did not address: 
 - Why are we returning Cells via std::make_unique()? It does an extra copy of the Cells which is pretty costly. Should we return via a shared_ptr, or a plain reference? 
 - Result::ColumnLatestCell(), Result::Size(), Result::FamilyMap(), Result::Map(), Result:: seem important to implement as well. 
 - In the java side, Result object implements various methods like getColumnLatestCell() using a binary search within the Cell[] because that Cell[] can be quite large. Let's add a TODO in the code for this, and revisit this in a later jira. 
 - When CellScanner from the other jira is in, should the Result implement CellScanner? It does so in java. We can leave that for later as well. 
 - In the offline discussions I was mentioning that ResultScanner will not be as it is in the patch. We would need the ResultScanner to be an pure abstract class, so that the scanners can implement the interface. We can leave out the ResultScanner from this patch and only have Result for now if we need more baking here. 

> [C++] Result and ResultScanner classes
> --------------------------------------
>
>                 Key: HBASE-17283
>                 URL: https://issues.apache.org/jira/browse/HBASE-17283
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Sudeep Sunthankar
>            Assignee: Sudeep Sunthankar
>         Attachments: HBASE-17283.HBASE-14850.v1.patch
>
>


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)