lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Rowe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-5463) Provide cursor/token based "searchAfter" support that works with arbitrary sorting (ie: "deep paging")
Date Tue, 10 Dec 2013 00:18:07 GMT

    [ https://issues.apache.org/jira/browse/SOLR-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13843748#comment-13843748
] 

Steve Rowe commented on SOLR-5463:
----------------------------------

{quote}
* searchAfter => cursor
* nextSearchAfter => cursorContinue
{quote}

+1

bq. I'm concerned people might think they can use the uniqueKey of the last document they
got on the previous page

I tried making this mistake (using the trailing unique id ("NOK" in this example) as the searchAfter
param value, and I got the following error message:

{code}
{
  "responseHeader":{
    "status":400,
    "QTime":2},
  "error":{
    "msg":"Unable to parse search after totem: NOK",
    "code":400}}
{code}

I think that error message should include the param name ({{cursorContinue}}) that couldn't
be parsed.

Also, maybe it would be useful to include a prefix that will (probably) never be used in unique
ids, to visually identify the cursor as such: like always prepending '*'?  So your example
of the future would become:

{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}

The error message when someone gives an unparseable {{cursor}} could then include this piece
of information: "cursors begin with an asterisk".

> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message