[
https://issues.apache.org/jira/browse/SLING-11230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Klco updated SLING-11230:
-----------------------------
Description:
*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.
was:
*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.
*Recommended Solution*
Instead, support parsing the start and limit values from the query via a
comment at the end of the query in the form:
/* slingQueryStart=9, slingQueryLimit=10 */
This has the advantage of already being ignored by the Oak implementation of
JCR-SQL2 and would be relatively easy to parse.
The JCR Resource Provider's Query Language Provider could then remove the
comment from the original query and set the limit and start values
appropriately.
*Alternative*
Understandably, manipulating queries may not be desirable and there's a not
insignificant possibility of backwards compatibility impact. As an alternative,
I would recommend adding a new package to the API specifically for query
support and in that provide a service interface and SPI for providers to
implement which supports:
- Queries with limits and offsets
- Queries returning Streams as well as Iterators
- Queries which automatically Adapt the result to the desired type
- A SPI class for lazy adaptation of Stream and Iterators
> 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)
