Improve paging functionality
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start by inspecting the Java SDK APIs named in the report: RequestConfiguration, RequestInformation, and PageIterator. Reproduce the sample paging flow and compare how query parameters are configured for the first and subsequent requests. Done means callers can configure paging query parameters without duplicating them or using encoded names such as "%24select" and "%24filter".
Written by the indexing model from the issue text.
Description
Is your feature request related to a problem? Please describe the problem.
In my opinion, the code required for getting all paged results of a collection request is not ideal. In v5 I had a generic method that handled it for all types, but I couldn't achieve the same using v6. Mainly because the classes for the original request use a RequestConfiguration object and the classes for the paginated requests use a RequestInformation object and they seem to be wholly incompatible.
This is the best I could come up with:
public List<User> getAllUsers(List<String> selectAttributes, String filter)
{
UserCollectionResponse userCollectionResponse = graphClient.users().get(
requestConfig ->
{
if (!selectAttributes.isEmpty())
{
requestConfig.queryParameters.select = selectAttributes.toArray(new String[0]);
if (selectAttributes.contains("manager"))
requestConfig.queryParameters.expand = new String[]{"manager"};
}
if (filter != null)
requestConfig.queryParameters.filter = filter;
});
UnaryOperator<RequestInformation> requestInformation =
requestInfo ->
{
if (!selectAttributes.isEmpty())
{
requestInfo.addQueryParameter("%24select", selectAttributes.toArray(new String[0]));
if (selectAttributes.contains("manager"))
requestInfo.addQueryParameter("%24expand", new String[]{"manager"});
}
if (filter != null)
requestInfo.addQueryParameter("%24filter", filter);
return requestInfo;
};
return loadPagedEntities(userCollectionResponse, UserCollectionResponse::createFromDiscriminatorValue, requestInformation);
}
private <T extends Parsable> List<T> loadPagedEntities(
BaseCollectionPaginationCountResponse baseCollectionPaginationCountResponse,
Function<ParseNode, BaseCollectionPaginationCountResponse> collectionPageFactoryFunction,
UnaryOperator<RequestInformation> requestInformation)
{
try
{
List<T> entities = new ArrayList<>();
PageIterator<T, BaseCollectionPaginationCountResponse> pageIterator =
new PageIterator.Builder<T, BaseCollectionPaginationCountResponse>()
.client(graphClient)
.collectionPage(Objects.requireNonNull(baseCollectionPaginationCountResponse))
.collectionPageFactory(collectionPageFactoryFunction::apply)
.requestConfigurator(requestInformation)
.processPageItemCallback(entities::add)
.build();
pageIterator.iterate();
return entities;
}
catch (ReflectiveOperationException e)
{
throw new RuntimeException(e);
}
}
What irks me most about this, is that I have to specify the query parameters twice and using different syntax! Especially the "%24..." is pretty ugly.
Describe the solution you'd like.
The best solution, of course, would be if the SDK handled this transparently:
List<User> allUsers = graphClient.users().getAll(requestConfig -> ...);
The next best solution would be some kind of compatibility between RequestConfiguration and RequestInformation, so the query parameters would only have to specified once.
What do you think?
Additional context?
No response
- Dominant language
- Java
- Stars
- 444
- Forks
- 154
- Avg merge
- 18h 28m
- Merged PRs (30d)
- 4
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoftgraph/msgraph-sdk-java
-
status:waiting-for-triage type:bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
microsoftgraph/msgraph-sdk-java#2610 ·
-
status:waiting-for-triage type:bug
Difficulty 3/5 1-2 days Newbie friendliness 55/100
microsoftgraph/msgraph-sdk-java#2656 ·
-
status:waiting-for-triage type:bug
Difficulty 4/5 3-5 days Newbie friendliness 38/100
microsoftgraph/msgraph-sdk-java#2654 ·
-
status:waiting-for-triage
Difficulty 4/5 3-5 days Newbie friendliness 35/100
microsoftgraph/msgraph-sdk-java#2639 ·
-
status:waiting-for-triage type:bug
Difficulty 3/5 1-2 days Newbie friendliness 35/100
microsoftgraph/msgraph-sdk-java#2589 · 1 comment ·
All issues in microsoftgraph/msgraph-sdk-java
Similar issues
-
certification
Difficulty 1/5 Under an hour Newbie friendliness 80/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
[BUG] ECR GetAuthorizationToken returns a proxyEndpoint for the default region, not the request's Openbug ecr
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Needs: Triage Type: Feature request
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
AntennaPod/AntennaPod#8794 ·
-
agentic-workflows
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
github/copilot-sdk#2760 ·