On 30 Jan 2012, at 20:07, Dietrich Featherston wrote:
> 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.
Just pushed a branch for this[1]: turned out to be really easy, a KeyIndex is
just a BinIndex with no suffix. You use it like this
val keys =
bucket.fetchIndex(KeyIndex.index).from(startKey).to(endKey).execute();
Sorry that it is not going to be any use to you, but thanks for the spur to add
it!
>
> 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.
>
No, no there isn't.
[1]
https://github.com/basho/riak-java-client/commit/8398f902c3db285b4217ad267800dc93f9ec96c7
>
> 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
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
