[jira] [Commented] (SOLR-6635) Cursormark should support skipping/goto functionality

["Michael Gibney (JIRA)" <ji...@apache.org>]

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

Michael Gibney commented on SOLR-6635:
--------------------------------------

It's possible that a more general approach to cursorMark could answer this and many other use cases. A couple of observations here, the first two probably obvious:
1. The {{cursorMark}} param defines a relative (contextual, as opposed to absolute-offset) insertion point into a sorted list of documents
2. The {{start}} param defines an offset of returned results _relative to the list index/insertion point_ defined by the {{cursorMark}} param
3. When used in conjunction with {{cursorMark}}, in principle there's no reason why the {{start}} param must be non-negative. 

The current implementation of {{cursorMark}}/{{nextCursorMark}} is stateless on the server-side, but as far as I can tell it only directly supports serial, forward-only paging. In order for the current implementation to support backward paging in a client application, state must be maintained in the client application (e.g., a stack of cursorMarks by way of which the most recent request was navigated to). 

If the current cursorMark implementation were tweaked to allow start/offset param to be negative, and to generate and return a totem for the last _and first_ (and possibly for each) document in a result window, this would introduce the possibility of bidirectional paging that is entirely stateless (client-side as well as server-side). It would also enable re-alignment of results, returning target totems in context, and overlapping over-requesting to allow a client application to "preview" whether it has reached the end (or beginning, for backward paging) of paged results. With some further tweaking, this approach could be extended to support arbitrary ("skip to the 'R's") or universal ("skip to the 'last' page of results") totems. 

As a point of reference, I've been involved in implementing [a related approach|https://github.com/upenn-libraries/solrplugins#2-arbitrary-index-order-result-windows] (leveraging the facet component) that supports goto/paging through arbitrary windows of index-sorted terms (using slightly different parameter syntax: {{target}}, {{offset}}, {{limit}}, and an extra response field specifying the _actual_ {{target_offset}}).

As [~hossman] says, "when start > 0 & cursorMark=*, it is functionally equivilent to no cursorMark being specified at all (ie: regular pagination) except that the use of the cursorMark param indicates to Solr that the client wnats the nextCursorMark to be computed." cursorMark is great, and I'd love to use it; I definitely think the introduction of this skipping/goto/offset functionality (esp. with direct support for fully stateless bidirectional paging) would facilitate the backward-compatible migration of client applications to cursorMark-based implementations.

> Cursormark should support skipping/goto functionality
> -----------------------------------------------------
>
>                 Key: SOLR-6635
>                 URL: https://issues.apache.org/jira/browse/SOLR-6635
>             Project: Solr
>          Issue Type: Improvement
>          Components: SearchComponents - other
>            Reporter: Thomas Blitz
>              Labels: cursormark, pagination, search, solr
>         Attachments: SOLR-6635.patch
>
>
> Deep pagination is possible with the cursormark.
> We have discovered a need to be able to 'skip' a number of results.
> Using the cursormark it should be possible to define a request with a skip parameter, allowing the cursormark to simple skip a number of articles, kinda like a goto, and then return results from that point in the resultset.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org