You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@accumulo.apache.org by Andrew Wells <aw...@clearedgeit.com> on 2014/10/24 16:53:02 UTC

Reasoning behind Key(Text row) using Long.MAX_VALUE

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 <aw...@clearedgeit.com>*

Re: Reasoning behind Key(Text row) using Long.MAX_VALUE

Posted by Josh Elser <jo...@gmail.com>.

What version are you seeing this in?

I seem to vaguely recall a similar issue a while back that was fixed...

Andrew Wells 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
>
>
>

Re: Reasoning behind Key(Text row) using Long.MAX_VALUE

Posted by Andrew Wells <aw...@clearedgeit.com>.

and a new lesson on ranges!!!

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

> No worries, no time wasted. The collective 'we' are always happy to answer
> questions. :)
>
> (fwiw, I still forget about timestamps being sorted in descending order
> most days)
>
>
> Andrew Wells wrote:
>
>> 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<el...@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<el...@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<vi...@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<aw...@clearedgeit.com>*
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   --
>>>>>>>>>>
>>>>>>>>> *Andrew George Wells*
>>>>>>>> *Software Engineer*
>>>>>>>> *awells@clearedgeit.com<aw...@clearedgeit.com>*
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   --
>>>>>>>>
>>>>>>> *Andrew George Wells*
>>>>>>> *Software Engineer*
>>>>>>> *awells@clearedgeit.com<aw...@clearedgeit.com>*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>
>>


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

Re: Reasoning behind Key(Text row) using Long.MAX_VALUE

Posted by Josh Elser <el...@apache.org>.

No worries, no time wasted. The collective 'we' are always happy to 
answer questions. :)

(fwiw, I still forget about timestamps being sorted in descending order 
most days)

Andrew Wells wrote:
> 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<el...@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<el...@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<aw...@clearedgeit.com>
>>>>> wrote:
>>>>>
>>>>>    John, that is probably true too...
>>>>>
>>>>>> On Fri, Oct 24, 2014 at 11:26 AM, Andrew Wells<aw...@clearedgeit.com>
>>>>>> wrote:
>>>>>>
>>>>>>    this would be in SNAPSHOT 1.6
>>>>>>
>>>>>>> On Fri, Oct 24, 2014 at 11:08 AM, John Vines<vi...@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<aw...@clearedgeit.com>*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   --
>>>>>>> *Andrew George Wells*
>>>>>>> *Software Engineer*
>>>>>>> *awells@clearedgeit.com<aw...@clearedgeit.com>*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   --
>>>>>> *Andrew George Wells*
>>>>>> *Software Engineer*
>>>>>> *awells@clearedgeit.com<aw...@clearedgeit.com>*
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>
>

Re: Reasoning behind Key(Text row) using Long.MAX_VALUE

Posted by Andrew Wells <aw...@clearedgeit.com>.

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 <el...@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<el...@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<aw...@clearedgeit.com>
>>>> wrote:
>>>>
>>>>   John, that is probably true too...
>>>>
>>>>> On Fri, Oct 24, 2014 at 11:26 AM, Andrew Wells<aw...@clearedgeit.com>
>>>>> wrote:
>>>>>
>>>>>   this would be in SNAPSHOT 1.6
>>>>>
>>>>>>
>>>>>> On Fri, Oct 24, 2014 at 11:08 AM, John Vines<vi...@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<aw...@clearedgeit.com>*
>>>>>>>>
>>>>>>>>
>>>>>>>>  --
>>>>>> *Andrew George Wells*
>>>>>> *Software Engineer*
>>>>>> *awells@clearedgeit.com<aw...@clearedgeit.com>*
>>>>>>
>>>>>>
>>>>>>
>>>>>>  --
>>>>> *Andrew George Wells*
>>>>> *Software Engineer*
>>>>> *awells@clearedgeit.com<aw...@clearedgeit.com>*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>>


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

Re: Reasoning behind Key(Text row) using Long.MAX_VALUE

Posted by Josh Elser <el...@apache.org>.

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<el...@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<aw...@clearedgeit.com>
>>> wrote:
>>>
>>>   John, that is probably true too...
>>>> On Fri, Oct 24, 2014 at 11:26 AM, Andrew Wells<aw...@clearedgeit.com>
>>>> wrote:
>>>>
>>>>   this would be in SNAPSHOT 1.6
>>>>>
>>>>> On Fri, Oct 24, 2014 at 11:08 AM, John Vines<vi...@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<aw...@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<aw...@clearedgeit.com>*
>>>>>>>
>>>>>>>
>>>>> --
>>>>> *Andrew George Wells*
>>>>> *Software Engineer*
>>>>> *awells@clearedgeit.com<aw...@clearedgeit.com>*
>>>>>
>>>>>
>>>>>
>>>> --
>>>> *Andrew George Wells*
>>>> *Software Engineer*
>>>> *awells@clearedgeit.com<aw...@clearedgeit.com>*
>>>>
>>>>
>>>>
>>>
>
>

Re: Reasoning behind Key(Text row) using Long.MAX_VALUE

Posted by Andrew Wells <aw...@clearedgeit.com>.

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 <el...@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<aw...@clearedgeit.com>
>> wrote:
>>
>>  John, that is probably true too...
>>>
>>> On Fri, Oct 24, 2014 at 11:26 AM, Andrew Wells<aw...@clearedgeit.com>
>>> wrote:
>>>
>>>  this would be in SNAPSHOT 1.6
>>>>
>>>>
>>>> On Fri, Oct 24, 2014 at 11:08 AM, John Vines<vi...@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<aw...@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<aw...@clearedgeit.com>*
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> *Andrew George Wells*
>>>> *Software Engineer*
>>>> *awells@clearedgeit.com<aw...@clearedgeit.com>*
>>>>
>>>>
>>>>
>>> --
>>> *Andrew George Wells*
>>> *Software Engineer*
>>> *awells@clearedgeit.com<aw...@clearedgeit.com>*
>>>
>>>
>>>
>>
>>


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

Re: Reasoning behind Key(Text row) using Long.MAX_VALUE

Posted by Josh Elser <el...@apache.org>.

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<aw...@clearedgeit.com>
> wrote:
>
>> John, that is probably true too...
>>
>> On Fri, Oct 24, 2014 at 11:26 AM, Andrew Wells<aw...@clearedgeit.com>
>> wrote:
>>
>>> this would be in SNAPSHOT 1.6
>>>
>>>
>>> On Fri, Oct 24, 2014 at 11:08 AM, John Vines<vi...@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<aw...@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<aw...@clearedgeit.com>*
>>>>>
>>>
>>>
>>> --
>>> *Andrew George Wells*
>>> *Software Engineer*
>>> *awells@clearedgeit.com<aw...@clearedgeit.com>*
>>>
>>>
>>
>> --
>> *Andrew George Wells*
>> *Software Engineer*
>> *awells@clearedgeit.com<aw...@clearedgeit.com>*
>>
>>
>
>

Re: Reasoning behind Key(Text row) using Long.MAX_VALUE

Posted by Andrew Wells <aw...@clearedgeit.com>.

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 <aw...@clearedgeit.com>
wrote:

> John, that is probably true too...
>
> On Fri, Oct 24, 2014 at 11:26 AM, Andrew Wells <aw...@clearedgeit.com>
> wrote:
>
>> this would be in SNAPSHOT 1.6
>>
>>
>> On Fri, Oct 24, 2014 at 11:08 AM, John Vines <vi...@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 <aw...@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 <aw...@clearedgeit.com>*
>>> >
>>>
>>
>>
>>
>> --
>> *Andrew George Wells*
>> *Software Engineer*
>> *awells@clearedgeit.com <aw...@clearedgeit.com>*
>>
>>
>
>
> --
> *Andrew George Wells*
> *Software Engineer*
> *awells@clearedgeit.com <aw...@clearedgeit.com>*
>
>


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

Re: Reasoning behind Key(Text row) using Long.MAX_VALUE

Posted by Andrew Wells <aw...@clearedgeit.com>.

John, that is probably true too...

On Fri, Oct 24, 2014 at 11:26 AM, Andrew Wells <aw...@clearedgeit.com>
wrote:

> this would be in SNAPSHOT 1.6
>
>
> On Fri, Oct 24, 2014 at 11:08 AM, John Vines <vi...@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 <aw...@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 <aw...@clearedgeit.com>*
>> >
>>
>
>
>
> --
> *Andrew George Wells*
> *Software Engineer*
> *awells@clearedgeit.com <aw...@clearedgeit.com>*
>
>


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

Re: Reasoning behind Key(Text row) using Long.MAX_VALUE

Posted by Andrew Wells <aw...@clearedgeit.com>.

this would be in SNAPSHOT 1.6


On Fri, Oct 24, 2014 at 11:08 AM, John Vines <vi...@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 <aw...@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 <aw...@clearedgeit.com>*
> >
>



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

Re: Reasoning behind Key(Text row) using Long.MAX_VALUE

Posted by John Vines <vi...@apache.org>.

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 <aw...@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 <aw...@clearedgeit.com>*
>