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
Activity
Closing because the cited issue has been fixed and OP promises to open a new issue to address sorting.
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.
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?
this should do it:
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?
