-
Notifications
You must be signed in to change notification settings - Fork 324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SQSERVICES-1773] Allow pagination for team search endpoint #2895
[SQSERVICES-1773] Allow pagination for team search endpoint #2895
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want to update JSON golden test files with an example where searchPagingState
is a Just
value? It's a bit weird to put Nothing
s in 20 existing cases and to none with a Just
value.
You are right. Done! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you aware of the Wire.API.Routes.MultiTablePaging
module and the paging facilities provided by it? If yes, why rolling your own pagination system?
@@ -136,7 +137,7 @@ searchLocally searcherId searchTerm maybeMaxResults = do | |||
esResult <- | |||
if esMaxResults > 0 | |||
then Q.searchIndex (Q.LocalSearch searcherId searcherTeamId teamSearchInfo) searchTerm esMaxResults | |||
else pure $ SearchResult 0 0 0 [] FullSearch | |||
else pure $ SearchResult 0 0 0 [] FullSearch Nothing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have the context here, but should maybe this be an input parameter to the searchLocally
function instead of always being Nothing
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function is part of the ConnectionAPI
and this API is not subject to change in this ticket/PR. If it is Nothing
then the behavior doesn't change. The only good reason I can think of to pass as parameter would be to make it more visible. Do you think we should do this?
@@ -113,7 +113,8 @@ searchRemotely domain searchTerm = do | |||
searchFound = count, | |||
searchReturned = count, | |||
searchTook = 0, | |||
searchPolicy = S.searchPolicy searchResponse | |||
searchPolicy = S.searchPolicy searchResponse, | |||
searchPagingState = Nothing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have the context here, but should maybe this be an input parameter to the searchRemotely
function instead of always being Nothing
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See answer to previous comment.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for clarifying! I'd say this is good to go.
https://wearezeta.atlassian.net/browse/SQSERVICES-1773
Checklist
changelog.d