Thanks, Christopher. It's nice to hear an unambiguous point of view :) Do you see any alternative way of implementing a range scan on a partitioned index? The problem does not exist for exact-match scans because the row ID in the index entry CQ provides the correct ordering.
Thanks, -Russ On Wed, Apr 1, 2015 at 9:11 PM, Christopher <[email protected]> wrote: > You should definitely not rely on this behavior. It goes against best > practices and is prone to error. It is not recommended. > > On Wed, Apr 1, 2015, 20:03 Russ Weeks <[email protected]> wrote: > > > A wonderful property of scan-time iterators is that they can emit row IDs > > in arbitrary order. Before I go off and build an index that relies on > this > > behaviour, I'd like to get a sense of how likely it is to exist in future > > versions of Accumulo. > > > > I'd like to build an index like this (hopefully the ascii comes through, > if > > not check here <https://gist.github.com/anonymous/1a64114da4b68a2ec822 > >): > > > > > > row | cf | cq | val > > ------------------------------------------------- > > p0 | i | (prop_a, 7, r15) | 1 > > p0 | i | (prop_a, 8, r8) | 1 > > p0 | i | (prop_a, 9, r19) | 1 > > [...snip...] > > p0 | d | (r8, prop_a) | 8 > > p0 | d | (r8, prop_b) | hello, world > > p0 | d | (r15, prop_a) | 7 > > p0 | d | (r15, prop_b) | just testing > > p0 | d | (r19, prop_a) | 9 > > p0 | d | (r19, prop_b) | something else > > > > Which is a pretty conventional partitioned index. I'd like to be able to > > issue a query like, "Tell me about prop_b for all documents where prop_a > < > > 9" but I'm pretty sure that the only way this could work at scale is if > > it's OK for the iterator to return (p0, r15, prop_b, "just testing") > > followed by (p0, r8, prop_b, "hello, world"). > > > > This works today - if you folks see any flaws in my reasoning please let > me > > know - my question is, do you see this as functionality that should be > > preserved in the future? > > > > Thanks, > > -Russ > > >
