On 4/13/14, 11:32 PM, Sean Busbey wrote:
Oh! that's ACCUMULO-1994. The ticket explains the root problem. In the
1.5.0 Proxy, the timestamp defaults to 0. Since columns sort on
timestamp in reverse order, that means nothing in the start row gets
included (unless the rest of the key components are 0).
[1]: https://issues.apache.org/jira/browse/ACCUMULO-1994
Bingo! That's entirely it, Sean.
On Sun, Apr 13, 2014 at 8:17 PM, David O'Gwynn <[email protected]
<mailto:[email protected]>> wrote:
Urgh. If I run your code with the 1.5.1 Thrift interface, behavior's
not there. If I run it with the one I downloaded, I get the behavior.
I diff'ed the ttypes.py from the old and new and got this:
< (5, TType.I64, 'timestamp', None, None, ), # 5
---
> (5, TType.I64, 'timestamp', None, 9223372036854775807, ), # 5
228c228
< def __init__(self, row=None, colFamily=None, colQualifier=None,
colVisibility=None, timestamp=None,):
---
> def __init__(self, row=None, colFamily=None, colQualifier=None,
colVisibility=None, timestamp=thrift_spec[5][4],):
I hand-jammed that timestamp default (sys.maxint) into my codebase and
presto: fixed. So, I was obviously working off of an old Thrift
interface version. Fail.
Still not sure why that would fix it. The skip condition in WRI's seek
method requires both that the timestamp be Long.MAX_VALUE and
Range.isStartKeyInclusive() be false. The only thing that I can think
is that the versioning iterator somehow resets the Range to the
correct defaults. [/shrug]
Regardless, I think the issue is actually settled. Again, thanks,
Josh, for the patience.
As always, HTH David. This is certainly one of those quirky bugs. I'm
glad we could get to the bottom of it :D
