[
https://issues.apache.org/jira/browse/SLING-11230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514593#comment-17514593
]
Bertrand Delacretaz commented on SLING-11230:
---------------------------------------------
Instead of changing the {{{}ResourceResolver{}}}, creating a new query service
interface the takes a {{ResourceResolver}} as an argument would IMHO be more
decoupled and modular. IIUC that's the intention of SLING-4752 but I haven't
looked in detail.
In terms of paginated result sets we have
[https://github.com/apache/sling-org-apache-sling-graphql-core/tree/master/src/main/java/org/apache/sling/graphql/api/pagination]
which is based on the [Relay Cursor Connections
spec|https://relay.dev/graphql/connections.htm]. That spec is meant for GraphQL
but I think we would use the same principles (and envelope output format maybe)
for any API, for consistency, if that works for your use cases.
Note that that spec is about cursor-based pagination, as opposed to
offset-based, and in the GraphQL Core we have only implemented the
"forward-only, infinite scroll" style. I think that's a good way of preventing
clients from doing crazy things, and putting the burden on the client if they
_really_ need back and forth navigation in the results. That can IMHO help
avoid creating undue load on servers in such cases, and prompt developers to no
go too far with pagination.
> Support Limit and Offset via JcrResourceProvider / findResources
> ----------------------------------------------------------------
>
> Key: SLING-11230
> URL: https://issues.apache.org/jira/browse/SLING-11230
> Project: Sling
> Issue Type: Improvement
> Components: JCR
> Reporter: Dan Klco
> Assignee: Dan Klco
> Priority: Minor
>
> *Problem Statement*
> In addition to not supporting global limits, there are good reasons that a
> developer may want to return only a sub-set of the query results when
> executing a query. For example returning the 10 latest uploaded files.
> Currently this can be accomplished by executing a query and then only
> iterating to the 10th item, however a much larger query set may be fetched
> from the node store than required to service the intended use case.
> In addition, to support paging, the current implementation would require
> retrieving and iterating over the Resources until the desired start point is
> found then reading the subsequent Resources.
> _However_ changing the API contract for the ResourceResolver to either add a
> new method with the start and limit values would have a non-insignificant
> ripple effect into the implementations, mocks and providers which would be
> required to support this new method.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
