accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dylan Hutchison (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-2817) Add offset and limit arguments to byte array Encoder.decode method
Date Thu, 23 Jun 2016 17:30:16 GMT

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

Dylan Hutchison commented on ACCUMULO-2817:
-------------------------------------------

Hi folks, I'm interested in calling {{decodeUnchecked(byte[], off, len)}} as public API, since
it removes the need to copy a subarray out from a larger array.

Looking back at the discussion on this patch, I can't figure out what the path was to making
decodeUnchecked public and adding it to the Lexicoder interface.  There was some debate involving
binary compatibility and semvar.  

One option is to create a new interface extending Lexicoder with the new method decodeUnchecked.
 It would maintain binary compatibility, at the cost of adding another interface that exists
only for binary compatibility reasons.  A few other options were suggested.  

> Add offset and limit arguments to byte array Encoder.decode method
> ------------------------------------------------------------------
>
>                 Key: ACCUMULO-2817
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2817
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client
>            Reporter: Josh Elser
>            Assignee: Matt Dailey
>              Labels: newbie
>             Fix For: 1.7.0
>
>         Attachments: ACCUMULO-2817.patch
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Similar to ACCUMULO-2445, but presently the encoder only works on complete byte arrays.
This forces an extra copy of the data when it is located in an array that contains other information
(e.g. a composite key).
> It would be nice to be able to provide offset and length arguments to {{Encoder.decode}}
so that users can avoid the additional arraycopy.
> Changing to a ByteBuffer instead of byte array argument would also be acceptable, but
more churn on the API that, unless it's happening globally, I would rather avoid. It would
also incur the penalty for that extra Object, which while minimal alone, could be significant
if decoding every value in a table, for example.



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

Mime
View raw message