Search API question (was: riak-erlang-client issue with Riak EE 1.2)

Julian jpellico at
Wed Aug 29 20:53:20 EDT 2012


I poked and prodded some more, and figured out that 'fl' is a field
filter that is useful to me, basically doing what I was doing with MR
in the prior version. (Would be nice to see an example of this in the
updated docs)

I noticed a couple things using the search API and have these comments/questions

1. Seems like the server squeezes an <<"id">> field at the start of
each result object. We already have an embedded "id" field in our json
objects, so I'm getting 2 <<"id">>'s here. It would be nice if this
were removed from the object fields, but clearly I could see how it's
useful to know the object key in its bucket, so a format like this
might be nicer
{<<"index">>, <<"key">>, [{<<"field1">>, <<"foo">>}, {<<"field2">>,

2. In my particular query, I'm getting a small number (5 out of 37) of
the fields repeated within each object at the end of the proplist. The
values, fortunately, are identical to the ones earlier in the object.
I wonder if this is related to indexing or something like that?
Unfortunately, I did not configure our Riak search and can't say
definitively whether I have secondary indices on those or not.


On Wed, Aug 29, 2012 at 12:54 PM, Dave Parfitt <diparfitt at> wrote:
> Hi Julian -
>    The riak-erlang-client docs definitely need to be updated for search, index, and map/reduce.
> In the meantime, if you notice on this line:
> you'll see that the type for Options is "search_options()".
> You can find the definition of search_options() here:
> and the definition for search_option() here:
> Cheers -
> Dave
> On Aug 28, 2012, at 7:20 PM, Julian wrote:
>> Sure, I see the source code of search/*, but I'm kind of stuck at
>> figuring out the search_options properties and whether they can help
>> me or not. I've made stabs at 'rows', 'start' and 'sort' and they're
>> more or less the intuitive thing (although I couldn't do a reverse
>> sort order if I had to).
>> I don't see any code in riak_pb that sheds enlightenment; I'm guessing
>> that this #rpbsearchqueryrec record is just shoved into a packet and
>> sent to the server.
>> search_options([{rows, Rows} | Rest], Req) ->
>>    search_options(Rest, Req#rpbsearchqueryreq{rows=Rows});
>> search_options([{start, Start} | Rest], Req) ->
>>    search_options(Rest, Req#rpbsearchqueryreq{start=Start});
>> search_options([{sort, Sort} | Rest], Req) ->
>>    search_options(Rest, Req#rpbsearchqueryreq{sort=Sort});
>> search_options([{filter, Filter} | Rest], Req) ->
>>    search_options(Rest, Req#rpbsearchqueryreq{filter=Filter});
>> search_options([{df, DF} | Rest], Req) ->
>>    search_options(Rest, Req#rpbsearchqueryreq{df=DF});
>> search_options([{op, OP} | Rest], Req) ->
>>    search_options(Rest, Req#rpbsearchqueryreq{op=OP});
>> search_options([{fl, FL} | Rest], Req) ->
>>    search_options(Rest, Req#rpbsearchqueryreq{fl=FL});
>> search_options([{presort, Presort} | Rest], Req) ->
>>    search_options(Rest, Req#rpbsearchqueryreq{presort=Presort});
>> search_options([{_, _} | _Rest], _Req) ->
>>    erlang:error(badarg).
>> Thanks,
>> Julian
>> On Tue, Aug 28, 2012 at 12:26 PM, Dave Parfitt <diparfitt at> wrote:
>>> Hello Julian -
>>> Map-reduce is still available, it's just not what riakc_pb_socket:search/* uses under the hood anymore. Both map/reduce and Riak search functionality are implemented in the client using Protocol Buffers now.
>>> The Map/Reduce functions are available here:
>>> and the Search functions are available here:
>>> Cheers -
>>> Dave

More information about the riak-users mailing list