Yeah I had something that I thought would work then ran into some assumptions about handling of the existing bin / int query types. Started to introduce a higher level Index type that a generic RangeQuery could operate on rather than playing the combinatorics game with the existing AbstractRangeQuery subclasses. Got hairy enough that it's probably a good idea to let someone who has ownership over the codebase do this.
In the end I'm not sure if I'll even be able to use the key range queries. Problem is that this only fetches the keys but what I really need is to fetch the values behind these keys. Doesn't look like there is a riak operation that maps onto a leveldb seek + scan in each of the partitions to pull a range of values. On Mon, Jan 30, 2012 at 11:54 AM, Russell Brown <[email protected]>wrote: > Hi Dietrich, > I'm actually doing it now. If you had a look at it you'll see it is a bit > of mess, what with the Query types and Index types and all that. I'm happy > to keep going and finish. > > Cheers > > Russell > > On 30 Jan 2012, at 18:58, Dietrich Featherston wrote: > > Hey Russel. Any thoughts on when you'd get around to pushing to master? > Since I'm actively working on this I'm happy to add KeyIndex to the RJC and > send a pull request if that would be quicker. > > > On Mon, Jan 30, 2012 at 10:51 AM, Dietrich Featherston <[email protected]> wrote: > >> That's perfect thanks. I think I was presuming that the name of the >> underlying index was $key_bin so this didn't cross my mind. Definitely >> agree with having a separated typed KeyIndex rather than changing how >> BinIndex or IntIndex work. >> >> Thanks, >> D >> >> >> On Mon, Jan 30, 2012 at 10:41 AM, Russell Brown <[email protected]>wrote: >> >>> >>> On 30 Jan 2012, at 18:12, Dietrich Featherston wrote: >>> >>> I'm using a leveldb-backed riak 1.0.2 and looking for some suggestions >>> to fetch a block of data by key range. I have control over the keys and all >>> reads out of this setup will involve at minimum a key range. It seems that >>> if leveldb is an ideal candidate for this kind of access pattern so long as >>> I'm able to take advantage of that in the APIs exposed by riak. >>> >>> First thought is to use the built-in $key index to do a query for the >>> keys falling in a range, then fetch the underlying objects (either directly >>> or via a map job). Doesn't look like this is yielding any results for a >>> range known to contain data, however. >>> >>> Doing something like the following in the Java API yields no data >>> >>> val keys = >>>> bucket.fetchIndex(BinIndex.named("$key")).from(startKey).to(endKey).execute(); >>> >>> >>> Whereas the same question phrased as a keyfilter map job does yield data >>> >>> riak.mapReduce(query) >>>> .addKeyFilter(new BetweenFilter(startKey, endKey)) >>>> .addMapPhase(new NamedErlangFunction("riak_kv_mapreduce", >>>> "map_object_value"), true) >>>> .execute() >>> >>> >>> Perhaps there is something I need to do to make sure the $key index is >>> built other than using the leveldb backend, but I couldn't find any >>> evidence of that in the docs. >>> >>> Does this seem like a reasonable approach? If so, any thoughts on how I >>> might be reading the key index incorrectly? >>> >>> >>> It is a bug/oversight in the RJC, when you do BinIndex.named("$key"), >>> you'll get an index called "$key_bin", which isn't the name of the index >>> you want. I'll raise a bug for it and get a patch out. I think the best bet >>> is to have a tagged type (KeyIndex ?) rather than change the way that >>> BinIndex/IntIndex work. Sound ok? >>> >>> Cheers >>> >>> Russell >>> >>> >>> Thanks, >>> D >>> >>> _______________________________________________ >>> riak-users mailing list >>> [email protected] >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >>> >>> >> > >
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
