Sorry, there's a minor error in my JSON - the "arg" key in the last phase
should be quoted.
2011/9/12 Sean Cribbs <s...@basho.com>
> Pagination can be non-trivial, but this feels like a good fit for secondary
> indexes rather than Search. Note that secondary indexes are only available
> in 1.0 (you can get a prerelease package from downloads.basho.com).
>
> I'd start off with a reduce phase that handles the pagination (since you
> know it's by key, it's easy to do up front), then you can add a map to fetch
> the documents and a final reduce/sort to make sure they are in the original
> order. This isn't exact because I don't know your document structure, but
> here's how you might do that:
>
> {
> "inputs": {
> "bucket": "order",
> "index": "contact_email_bin",
> "key": "firstname.lastn...@company.com"
> },
> "query":[
>
> {"reduce":{"language":"erlang","module":"riak_kv_mapreduce","function":"reduce_identity"}},
> {"reduce":{"language":"javascript", "name":"paginateOrders", "arg":
> 1}},
> {"map":{"language":"javascript", "name":"Riak.mapValuesJson"}},
> {"reduce":{"language":"javascript", "name":"Riak.reduceSort",
> "keep":true, arg:"function(a,b){ return a.Order.OrderNumber >
> b.Order.OrderNumber; }"}}
> ]
> }
>
> The first reduce makes sure the keys emitted can be passed to the
> pagination function in Javascript. If you are using Erlang for the function,
> you might not need this. Your paginateOrders function (assuming stored as a
> built-in) would look like this:
>
> function(values, page){
> // Set the page size here, or possibly set as an argument
> var pageSize = 30;
> // Sort on the key, descending.
> values = values.sort(function(a,b){ return parseInt(a[1]) <
> parseInt(b[1]); });
> return values.slice((page - 1) * pageSize, page * pageSize);
> }
>
> Note the Riak.reduceSort function can take a comparator function as a
> string arg and will evaluate it and pass it to the Array.sort function.
>
> 2011/9/12 Fredrik Lindström <fredrik.lindst...@qbranch.se>
>
>> Hi Sean,
>> thank you for the clarification. In our scenario a user might have many
>> orders so it would be nice to be able to page through the result set in
>> descending order.
>> Since our OrderNumbers are guaranteed to be unique we are currently using
>> them as the keys in Riak. They numbers are also created sequentially, hence
>> the desire to page through them in descending order giving the user a
>> chronological perspective of placed orders.
>>
>> We're still quite early in the process of evaluating Riak for our project
>> so we have plenty of time to try other approaches.
>>
>> /F
>> ------------------------------
>> *From:* Sean Cribbs [s...@basho.com]
>> *Sent:* Monday, September 12, 2011 3:53 PM
>> *To:* Fredrik Lindström
>> *Cc:* riak-users@lists.basho.com
>> *Subject:* Re: riaksearch 0.14.2 via solr: sort desc
>>
>> Fredrik,
>>
>> Unfortunately, because of limitations in Riak Search 0.14.x, it can only
>> (pre-)sort reliably on the document ID. However, it seems like OrderNumber
>> might be a natural ID for this document? If so, you could do something like
>> the following:
>>
>> http://riak/solr/order/select?rows=1&presort=key&q=
>> Order_Contact_Email:firstname.lastn...@company.com
>>
>> However, this query will also return in ascending order. If you just want
>> the highest order number, then feeding this query to MapReduce and
>> processing it there would seem appropriate.
>>
>> 2011/9/12 Fredrik Lindström <fredrik.lindst...@qbranch.se>
>>
>>> Hi everyone,
>>> does the "sort=myfieldname desc" parameter in riaksearch 0.14.2 (via
>>> solr) only sort within the current result set dictated by rows=x and start
>>> =y?
>>>
>>> I can get my search results in the correct ASC order regardless of the
>>> rows and start parameters.
>>> Sorting in DESC with rows=1 and start=0 I get one (obviously) result but
>>> the result actually appears to be in ASC order. The doc returned in the
>>> search result is the one with the lowest integer value in the field used for
>>> sorting.
>>>
>>> I'm quite new to Riak and Riak Search and therefore I assume that the
>>> error is on my part.
>>>
>>> Some technical details:
>>>
>>> Total objects in "order" bucket: 187
>>>
>>> Query with DESC sort:
>>>
>>> http://riak/solr/order/select?rows=1&start=0&sort=Order_OrderNumber%20desc&q=Order_Contact_Email:firstname.lastn...@company.com
>>> Result: 1 doc with Order_OrderNumber = 362982 (Expected result in my
>>> world of fantasy would be 621738 which is currently the highest value)
>>>
>>> Query with ASC sort:
>>>
>>> http://riak/solr/order/select?rows=1&start=0&sort=Order_OrderNumber%20asc&q=Order_Contact_Email:firstname.lastn...@company.com<http://riak/solr/order/select?rows=1&start=0&sort=Order_OrderNumber%20desc&q=Order_Contact_Email:firstname.lastn...@company.com>
>>> Result: 1 doc with Order_OrderNumber = 362982
>>>
>>> I have a custom schema where I have defined the field I want to sort by
>>> in the following way:
>>> {field, [
>>> {name, "Order_OrderNumber"},
>>> {type, integer},
>>> {analyzer_factory, {erlang, text_analyzers,
>>> integer_analyzer_factory}}
>>> ]},
>>>
>>> If I run the DESC query with rows=187 the results are ordered in the
>>> correct descending order.
>>>
>>> /F
>>>
>>>
>>> _______________________________________________
>>> riak-users mailing list
>>> riak-users@lists.basho.com
>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>>
>>>
>>
>>
>> --
>> Sean Cribbs <s...@basho.com>
>> Developer Advocate
>> Basho Technologies, Inc.
>> http://www.basho.com/
>>
>>
>
>
> --
> Sean Cribbs <s...@basho.com>
> Developer Advocate
> Basho Technologies, Inc.
> http://www.basho.com/
>
>
--
Sean Cribbs <s...@basho.com>
Developer Advocate
Basho Technologies, Inc.
http://www.basho.com/
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
