Offset/limit parameters don't seem to be respected in GET /favorites

Description

This is definitely true when the caller has a small number of favorites (<15?). I have not tested with a large number of favorites. The behavior also does not match the REST docs, which state that the default limit is 10.

e.g. the following requests all yield the entire list of 15 favorited entities:

GET /repo/v1/favorite?offset=0&limit=200
GET /repo/v1/favorite?offset=0&limit=10
GET /repo/v1/favorite?offset=0&limit=5
GET /repo/v1/favorite?offset=15&limit=10

Environment

None

Activity

Show:
Bruce Hoff
March 8, 2021, 4:26 PM

Closing because the cited issue has been fixed and OP promises to open a new issue to address sorting.

Nick Grosenbacher
March 8, 2021, 4:20 PM

good catch, looks like the sort in SWC happens in EntityBrowserUtils.

I’ll open new issues for adding ORDER BY to the API, and then using it in SWC.

Bruce Hoff
March 4, 2021, 11:53 PM

limit and offset definitely work on staging. One question though: When I look at my favorites in the Synapse web portal they appear sorted by project name, but the results from the service do not. (See below.) So I assume that the portal is sorting the results it gets from the service. If so then a series of paginated requests will result in the cumulative results being out of order. Do you want to change the query underlying the service to add an 'order by' clause?

Nick Grosenbacher
February 24, 2021, 5:45 PM

this should do it:

Bruce Hoff
February 19, 2021, 3:39 PM

You are right, the error is in SELECT_FAVORITES_HEADERS_SQL in DBOFavoriteDAOImpl. The SQL omits LIMIT and OFFET altogether. Would you care to fix it?

Fixed

Assignee

Nick Grosenbacher

Reporter

Nick Grosenbacher

Validator

Bruce Hoff

Priority

Major

Labels

None

Development Area

None

Sprint

None

Fix versions

Release Version History

None

Story Points

None

Epic Link

None

Slack Channel

None