Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <1141043451.1250209154847.JavaMail.jira@brutus>
Date: Thu, 13 Aug 2009 17:19:14 -0700 (PDT)
From: "Jonathan Gray (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.apache.org
Subject: [jira] Updated: (HBASE-1765) Delay Result deserialization until
 asked for and permit access to the raw binary to prevent forced
 deserialization
In-Reply-To: <1803428402.1250202554968.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jonathan Gray updated HBASE-1765:
---------------------------------

    Attachment: HBASE-1765-v2.patch

Adds new test TestSerialization.testResultDynamicBuild() which uncovers bug in first patch.

New patch passes this test and passes all client tests that I've run.

> Delay Result deserialization until asked for and permit access to the raw binary to prevent forced deserialization
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-1765
>                 URL: https://issues.apache.org/jira/browse/HBASE-1765
>             Project: Hadoop HBase
>          Issue Type: Improvement
>          Components: client
>    Affects Versions: 0.20.0
>            Reporter: Jonathan Gray
>            Assignee: Jonathan Gray
>             Fix For: 0.20.1, 0.21.0
>
>         Attachments: HBASE-1765-v1.patch, HBASE-1765-v2.patch
>
>
> We have our own API that we use to access HBase from other languages like erlang, python, c, etc...
> The Java gateway that maps from the actual HBase API to our internal API wants to pass the raw binary received for a Result.  As is, we have to deserialize into an array of KeyValues and then re-serialize into a flat byte[].
> We would like to propose modifying Result to not build the KeyValue[] until it's asked for via client methods (.raw() or .sorted() or any of the map methods).  This is already how the map methods work (we don't build the map until it's asked for the first time).
> The only API change would be adding an additional Result.getBytes() method the get the raw underlying byte[] that was sent from the server.  
> The Result.readFields(DataInput) would then only read in the full byte[].  Would add an additional private method Result.readFields() that generated the KeyValue[].  That would be called whenever a client asks for anything besides .getBytes().
> Since all access to Result is done through those methods (KeyValue[] private and not directly accessible w/o using those methods) this should not impact any existing code.
> Thoughts?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.