[
https://issues.apache.org/jira/browse/OLINGO-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876507#comment-13876507
]
M Carissimi commented on OLINGO-27:
-----------------------------------
Ralf, Stephan,
thanks for your comments. It's good to see that version 4.0 of the protocol
allows you to force the use of $filters, we might use it in future when we have
a 4.0 compliant service.
For the time being, we had already considered to stop adding the next link to a
page to avoid retrieval of data over a certain limit. This is an easy way to
stop too much data being loaded, but it does not inform the client that more
data is indeed available. Similarly returning error 400 might indicate the
request was not accepted, but again it does not give the client any indication
of what should be done to retrieve the data.
Would a default redirect to $top=MAXROWS be a better solution here? If a client
requests all data for an EntitySet, we could redirect the request to an URL
with $top=MAXROWS. In this case we would not have to return an error code and
we would still be compliant with the specification.
Do you know how OData clients generally behave with redirection? Is redirection
something that the protocol supports?
Cheers
Miki
> JPA server side paging
> ----------------------
>
> Key: OLINGO-27
> URL: https://issues.apache.org/jira/browse/OLINGO-27
> Project: Olingo
> Issue Type: New Feature
> Components: odata2-jpa
> Affects Versions: V2 1.1.0
> Environment: OS X, Linux, Windows
> Reporter: Carl J. Mosca
> Assignee: Chandan V.A
> Priority: Blocker
> Labels: paging
>
> Server side paging is required for our use case. A configurable hard-limit
> on page size is also needed.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)