Lol. Search JIRA before banging head against wall. Noted. :-D
On Sun, Apr 13, 2014 at 11:32 PM, Sean Busbey <[email protected]> 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 > > > On Sun, Apr 13, 2014 at 8:17 PM, David O'Gwynn <[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. >> >> On Sun, Apr 13, 2014 at 10:00 PM, Josh Elser <[email protected]> wrote: >> > On 4/13/14, 9:13 PM, David O'Gwynn wrote: >> >> >> >> If the versioning iterator is attached, and the WRI's priority is <= >> >> the versioning iterator's priority, then you see this behavior (the >> >> first row of a WRI scan gets dropped). If you change the priority for >> >> the WRI in your code to <=20, then you'll see it, Josh. >> >> >> >> Still not sure why this would be the case; seems an odd behavior. >> >> Anyway, thanks for taking the time to help me suss this out.:-) >> > >> > >> > Hrm, interesting. >> > >> > What you described with the versioning iterator doesn't make much sense, >> > but >> > I tried it out anyways. Setting WRI below versioning didn't change the >> > results. Also, completely removing the versioning iterator didn't change >> > anything. >> > >> > For fun, I inserted some new values for the same key and ensured that I >> > got >> > both values when versioning was configured below. >> > >> > I'm still not sure what exactly the root of your problem. > > > > > -- > Sean
