[
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: [email protected]
For additional commands, e-mail: [email protected]
