microsoftgraph / microsoftgraph/msgraph-sdk-java

Improve v6 for better Generics usage

Ouverte
#2,320 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

status:waiting-for-triage type:feature
Langage dominant
Java
Étoiles
444
Forks
154
Merge moyen
18 h 28 min
PR mergées (30 j)
4

Description

Is your feature request related to a problem? Please describe the problem.

We are trying to use v6 with generic methods to reduce duplicate boiler plate code, but struggle to do this efficiently. We struggled with the following:

  1. GetRequestConfiguration
    This class seems to be part of each Builder class and there is not one abstract parent implementation for all Builder classes. We can't write a generic method handling each entity because there are hundreds of seperate GetRequestConfiguration implementations, e.g. one for UsersRequestBuilder and this method now can only be used for UsersRequestBuilder:
public static Consumer<UsersRequestBuilder.GetRequestConfiguration> addAdvancedQueryCapabilities() {
		return cust -> {
			Objects.requireNonNull(cust.queryParameters).count = true;
			cust.headers.add("ConsistencyLevel", "eventual");
		};
	}

The same applies for PostRequestConfiguration and all other classes.

  1. BaseCollectionPaginationCountResponse
    Here we see some problems:
  • This class is not typed at all. In v5 there is a generic return type of the response class which determines the correct class for the actual item values in the page collection.
  • After the typing you could add getValue to the base class and not implement it in each subclass which should help to determine the actual return type in v6 as well.
  • Also we think as improvement createFromDiscriminatorValue should be overwritten in each subclass with it's correct implementation (I think this is already done), but we don't understand why we have the need to manually pass the correct descriminator to the PageIterator. We believe this can be done automatically without manual interaction.

Our call currently looks like this using a similar PageIterator as seen in here:

UserCollectionResponse page = userCollectionRequest.get(customizer);
List<User> users = RequestUtils.collectListFromAllPages(this.graphClient.getGraphServiceClient(), page,
	UserCollectionResponse::createFromDiscriminatorValue, this.getClass());

We already pass a UserCollectionResponse but we don't understand why the PageIterator does not get it's discriminator automatically and we have to set it manually by passing the explicit discriminator.

Also we can't use var users = ..., because we need to declare the return type as Entity and can't get it from UserCollectionResponse since that class is not typed.

What do you think about this?

Describe the solution you'd like.

For 1)
Use interfaces for the Configurators, such that generic implementations can be done using these interfaces.

For 2:
Already proposed above

Additional context?

No response

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez par lire les implémentations de GetRequestConfiguration dans les classes Builder, puis examinez BaseCollectionPaginationCountResponse, UserCollectionResponse et l’utilisation de PageIterator. Le résultat proposé par l’issue est la prise en charge de configurateurs génériques, des réponses de collections typées et une gestion moins manuelle des discriminateurs ; aucun fichier ni test précis n’est nommé.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
java
Domaine
api
Type d'issue
Fonctionnalité
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
À l'abandon
Clarté
À clarifier
Accessibilité débutants
25/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.