accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wells <awe...@clearedgeit.com>
Subject Re: Reasoning behind Key(Text row) using Long.MAX_VALUE
Date Fri, 24 Oct 2014 16:48:19 GMT
Okay. I am having an issue between the keyboard the and chair... I was
being told of an issue along the lines of exact matches, its possible that
issue is somewhere else, like in our code.

And I was internally forgetting that timestamp is sorted in reverse order.
sorry for wasting time.

On Fri, Oct 24, 2014 at 12:16 PM, Josh Elser <elserj@apache.org> wrote:

> What you're asking for with the startKey created by the Range already
> happens. Check out:
>
> https://github.com/apache/accumulo/blob/1.6/core/src/
> main/java/org/apache/accumulo/core/data/Range.java#L124
>
> The constructor for Key which accepts a startRow already makes the Key
> with a timestamp of Long.MAX_VALUE.
>
> But, the end key for that Range which you provided is also wrong as it
> wouldn't include any columns within that row.
>
> However, I had thought you were saying that the proxy was doing something
> different (incorrect) as compared to the Java API. Are you saying that you
> think the Java API is wrong? Sorry I didn't clarify earlier.
>
>
> Andrew Wells wrote:
>
>> Maybe we can change:
>>
>> public Range(Text row) {
>>    this(row, true, row, true);
>> }
>>
>> to
>>
>> public Range(Text row) {
>> this( (startRow == null ? null : new Key(startRow,Long.MAX_VALUE) ) ,
>> true,
>> (endRow == null ? null : new Key(endRow, 0)), true);
>> }
>>
>>
>> On Fri, Oct 24, 2014 at 12:00 PM, Josh Elser<elserj@apache.org>  wrote:
>>
>>  Oh good. That was the ticket I was vaguely remembering :)
>>>
>>> I have only done cursory poking with the proxy myself. I assume the
>>> general approach we'd want the proxy to follow is to match exactly how
>>> the
>>> Java API works. If you're seeing a discrepancy, that's definitely
>>> something
>>> we want to change.
>>>
>>>
>>> Andrew Wells wrote:
>>>
>>>  Also, i just found this: https://issues.apache.org/
>>>> jira/browse/ACCUMULO-1994
>>>>
>>>> which might be why its currently Long.MAX_VALUE
>>>>
>>>> So maybe a change in the Range implementation, not familiar with Proxy
>>>>
>>>> On Fri, Oct 24, 2014 at 11:36 AM, Andrew Wells<awells@clearedgeit.com>
>>>> wrote:
>>>>
>>>>   John, that is probably true too...
>>>>
>>>>> On Fri, Oct 24, 2014 at 11:26 AM, Andrew Wells<awells@clearedgeit.com>
>>>>> wrote:
>>>>>
>>>>>   this would be in SNAPSHOT 1.6
>>>>>
>>>>>>
>>>>>> On Fri, Oct 24, 2014 at 11:08 AM, John Vines<vines@apache.org>
>>>>>>  wrote:
>>>>>>
>>>>>>   Makes me think the Range(Text row) constructor should be row, true,
>>>>>>
>>>>>>> row,
>>>>>>> false
>>>>>>>
>>>>>>> On Fri, Oct 24, 2014 at 10:53 AM, Andrew Wells<
>>>>>>> awells@clearedgeit.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>   It may be need to change either the implementation of Key::new(Text
>>>>>>> row),
>>>>>>>
>>>>>>>  or change the way Range::exact(Text row) matches
>>>>>>>>
>>>>>>>> Trace on Key::new(Text row)
>>>>>>>> line: 102
>>>>>>>> line: 75
>>>>>>>>
>>>>>>>>
>>>>>>>> Trace on Range exact(Text row)
>>>>>>>> line 656
>>>>>>>> line 82
>>>>>>>> line 123
>>>>>>>>
>>>>>>>> This causes Range exact(Text row) to never match
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> *Andrew George Wells*
>>>>>>>> *Software Engineer*
>>>>>>>> *awells@clearedgeit.com<awells@clearedgeit.com>*
>>>>>>>>
>>>>>>>>
>>>>>>>>  --
>>>>>> *Andrew George Wells*
>>>>>> *Software Engineer*
>>>>>> *awells@clearedgeit.com<awells@clearedgeit.com>*
>>>>>>
>>>>>>
>>>>>>
>>>>>>  --
>>>>> *Andrew George Wells*
>>>>> *Software Engineer*
>>>>> *awells@clearedgeit.com<awells@clearedgeit.com>*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>>


-- 
*Andrew George Wells*
*Software Engineer*
*awells@clearedgeit.com <awells@clearedgeit.com>*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message