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

Brian Loss commented on ACCUMULO-1994:
--------------------------------------

Actually, I investigated this further, and it appears that getRowRange doesn't 
work at all.  The start and end of the range are the same Key (one with the 
supplied row as the row and Long.MAX_VALUE as the timestamp).

> proxy does not handle Key timestamps correctly
> ----------------------------------------------
>
>                 Key: ACCUMULO-1994
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1994
>             Project: Accumulo
>          Issue Type: Bug
>          Components: proxy
>    Affects Versions: 1.4.4, 1.5.0, 1.6.0, 1.6.1
>            Reporter: Brian Loss
>
> The proxy thrift IDL does not declare any default values for the Key struct.  
> This means that timestamp will default to 0.  However, in Java it defaults to 
> Long.MAX_VALUE.  This means that ranges created through the proxy may behave 
> differently than ranges created in Java.  For example, say in Ruby I create a 
> range as follows
> {code}
> range = Range.new(:start => Key.new(:row => "row1"), :startInclusive => true, 
> :stop => Key.new(:row => "row2"), :stopInclusive => true)
> {code}
> This range will not include any keys in row1 that don't have a column family, 
> qualifier, or visibility since timestamp of 0 sorts last.  If I created the 
> same range in Java, those keys would be included.
> Change the thrift IDL to declare 0x7FFFFFFFFFFFFFFF (Long.MAX_VALUE) as the 
> default value for timstamp so that the thrift-generated Key class behaves the 
> same way as the Java version.
> [~kturner] pointed me to the getRowRange helper method on the AccumuloProxy 
> service.  This method helps in some cases, but not the case I mentioned above 
> since I have two arbitrary rows.  Also, in looking through the code in 
> ProxyServer, Keith noticed that the code does not seem to handle timestamps 
> correctly.  For example, the getRowRange method does not pass a timestamp at 
> all (not even the EMPTY value).  Also, the internal helper method getProxyKey 
> ignores the timestamp on the incoming key.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Reply via email to