[
https://issues.apache.org/jira/browse/SOLR-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13843687#comment-13843687
]
Hoss Man commented on SOLR-5463:
--------------------------------
The one significant change i still want to make before abandoming this straw
man and moving on to using PaginatingCollector under the covers is to rethink
the vocabulary.
at the Lucene/IndexSearcher level, this functionality is leveraged using a
"searchAfter" param which indicates the exact "FieldDoc" returned by a previous
search. The name makes a lot of sense in this API given that the FieldDoc you
specify is expected to come from a previous search, and you are specifying that
you want to "search for documents after this document" in the ocntext of the
specified query/sort.
For the Solr request API however, I feel like this terminology might confuse
people. I'm concerned people might think they can use the uniqueKey of the
last document they got on the previous page (instead of realizing they need to
specify the special token they were returned as part of that page).
My thinking is that from a user perspective, we should call this functionality
a "Result Cursor" and rename the request param and response key appropriately.
something along the lines of...
{code:title=http://localhost:8983/solr/deep?q=*:*&rows=20&sort=id+desc&cursor=AoEjTk9L}
{
"responseHeader":{
"status":0,
"QTime":7},
"response":{"numFound":32,"start":-1,"docs":[
// ... docs here...
]
},
"cursorContinue":"AoEoMDU3OUIwMDI="}
{code}
* searchAfter => cursor
* nextSearchAfter => cursorContinue
What do folks think?
> Provide cursor/token based "searchAfter" support that works with arbitrary
> sorting (ie: "deep paging")
> ------------------------------------------------------------------------------------------------------
>
> Key: SOLR-5463
> URL: https://issues.apache.org/jira/browse/SOLR-5463
> Project: Solr
> Issue Type: New Feature
> Reporter: Hoss Man
> Assignee: Hoss Man
> Attachments: SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch,
> SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch,
> SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch,
> SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch,
> SOLR-5463__straw_man.patch
>
>
> I'd like to revist a solution to the problem of "deep paging" in Solr,
> leveraging an HTTP based API similar to how IndexSearcher.searchAfter works
> at the lucene level: require the clients to provide back a token indicating
> the sort values of the last document seen on the previous "page". This is
> similar to the "cursor" model I've seen in several other REST APIs that
> support "pagnation" over a large sets of results (notable the twitter API and
> it's "since_id" param) except that we'll want something that works with
> arbitrary multi-level sort critera that can be either ascending or descending.
> SOLR-1726 laid some initial ground work here and was commited quite a while
> ago, but the key bit of argument parsing to leverage it was commented out due
> to some problems (see comments in that issue). It's also somewhat out of
> date at this point: at the time it was commited, IndexSearcher only supported
> searchAfter for simple scores, not arbitrary field sorts; and the params
> added in SOLR-1726 suffer from this limitation as well.
> ---
> I think it would make sense to start fresh with a new issue with a focus on
> ensuring that we have deep paging which:
> * supports arbitrary field sorts in addition to sorting by score
> * works in distributed mode
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
