[
https://issues.apache.org/jira/browse/SOLR-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13856498#comment-13856498
]
Hoss Man commented on SOLR-5463:
--------------------------------
bq. I accidentally discovered that a blank cursorMark request param is ignored
- is this intentional? I ask because although
CursorMark.parseSerializedTotem("") throws an exception about the bad format of
an empty totem, QueryComponent.prepare() ignores a blank cursorMark param:
Yeah .. that was intentional. My thinking was that from CursorMark's
perspective, attempting to parse a null or blank string was not valid -- but
from QueryComponent's perspective, a null or blank string ment "do not
construct a CursorMark object at all"
the basic motivation being that it didn't seem like it should be an error to
have something like {{/select?q=foo&cursorMark=&...}} ... but i'm not adamant
that it should work that way.
In fact, thinking about it more, and looking at how some other params (like
start, rows, facet, etc...) deal with blank strings, i agree with you -- it
should be an error.
----
bq. What would be cool is if {{start}} could be the number of docs in previous
pages.
{{PagingFieldCollector.collect()}} throws this info away now though.
Yeah ... i was initially thinking that "-1" or some other marker value would be
handy to help make it clear that they shouldn't infer any meaning from it when
using a cursor -- but then i realize that was probably more dangerous then just
using "0" because at least then there was less risk of confusing off by 1
errors if they blindly use it in some context (but i forgot to remove those
nocommit questions)
if you can see an easy way to get the "real" number from
{{PagingFieldCollector}} that might be handy too ... i'm not sure.
I'm perfectly happy with a fixed value of 0 at the moment ... it could always
be revisted in the future.
> 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.patch, SOLR-5463.patch, SOLR-5463.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,
> SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch,
> SOLR-5463__straw_man__MissingStringLastComparatorSource.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.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
