Elasticsearch: Complétude du client REST Java de haut niveau

J'ai mis à jour la description du problème en attribuant à chaque API un rang de 1 à 3 en fonction de la difficulté d'ajouter sa prise en charge au client REST de haut niveau. Les critères étaient principalement la taille de la demande à sérialiser et la taille de la réponse à analyser.

merci @javanna - J'ai séparé les API en listes « importants » et « facultatifs », où les API facultatives sont celles qui seront rarement utilisées à partir d’applications autres que les applications de surveillance ou les tests. Si quelqu'un n'est pas d'accord avec ma sélection, n'hésitez pas à mentionner quelles API doivent être marquées comme importantes.

Je n'utilise pas encore le client REST de haut niveau, mais je me serais vraiment attendu à ce que le multi-get soit pris en charge.

@javanna C'est peut-être une question stupide, mais : de quelle manière quelqu'un récupère-t-il une API et commence-t-il à travailler dessus ? Sans risquer que quelqu'un fasse de même. : )

@javanna C'est peut-être une question stupide, mais : de quelle manière quelqu'un récupère-t-il une API et commence-t-il à travailler dessus ? Sans risquer que quelqu'un fasse de même. : )

Vous ajoutez ici un commentaire disant que vous y travaillez.

Merci @nik9000 !

J'ai choisi Créer un index.

J'ai ramassé "les indices existent".

Pour les questions liées au code (comment exécuter un test, quels tests sont (non) nécessaires, avons-nous besoin de la version asynchrone d'une méthode, etc.) est-ce que je pose ici, dans un numéro séparé ou sur les forums ? Ou autre chose? : )

salut @hariso, cela dépend de la question :) Il est probablement préférable d'ouvrir un PR même s'il s'agit d'un travail en cours, afin que nous puissions y discuter de vos questions. Cela marcherait-il pour toi?

Ce serait certainement le cas. Merci d'avoir répondu!

Salut, il serait très utile d'avoir 'mise à jour par requête' exposé dans le nouveau client.

Merci!

analyser (main) !

Salut,
Aurons-nous la fonctionnalité « Liste d'indices » dans le client de repos de haut niveau ? Je pense qu'il s'agit d'une API utile et importante pour de nombreuses tâches d'exploitation de cluster ES.

En plus de cela, si je recherche une API pour vérifier la taille des fragments d'un index, l'API "indices stats" est-elle conçue pour couvrir ce besoin ?

Actuellement, je travaille sur un outil de gestion de cluster et je recherche un client java rest "cross-version" pour ES. S'il n'y a pas de meilleur choix, je peux peut-être aider à contribuer ces fonctionnalités au client de haut niveau :)

À mon avis, il y a un défaut majeur dans le client de repos de haut niveau actuel. Toutes les méthodes qui exécutent les requêtes sont marquées comme finales. Cela crée un problème lorsque vous essayez de vous moquer du RestHighLevelClient. Peut-être qu'une interface pourrait être définie que le RestHighLevelClient peut implémenter ?

@sowelie Cela pourrait vous donner plus d'informations : #27238. J'utilise Mockito et je n'ai eu aucun problème à me moquer de RestHighLevelClient, même si j'ai eu un problème avec IndicesClient.

@hariso J'ai fini par créer une interface pour les méthodes dont j'avais besoin et sous-classer RestHighLevelClient. Cependant, je suppose qu'il existe une extension à mockito qui peut être utilisée pour se moquer des classes / méthodes finales. Le pull que vous avez référencé n'explique pas pourquoi les méthodes doivent être définitives. Savez-vous pourquoi c'est?

@sowelie certaines méthodes ont été rendues définitives car elles ne sont pas destinées à être sous- RestHighLevelClient n'est pas définitif car il peut être étendu en y ajoutant de nouvelles méthodes (pensez à ajouter la prise en charge des plugins qui ajoutent des points de terminaison personnalisés à Elasticsearch). De telles méthodes personnalisées peuvent utiliser les méthodes protégées internes perform* existantes qui sont le cœur de la classe elle-même. Nous ne voulons pas que le noyau de cette classe soit également potentiellement réécrit par des sous-classes. Pour moi, un gros défaut aurait été l'inverse, d'avoir des méthodes non définitives sans raison claire.

Je vous entends cependant sur les questions de moquerie et j'aimerais comprendre ce que vous faites différemment par rapport à ce que fait

search_after support de
Toutes nos excuses si un nouveau problème est le meilleur endroit pour les demandes.

@halfninja pour autant que je search_after est déjà pris en charge dans le cadre de l'API de recherche. Est-ce que j'ai raté quelque chose ?

@javanna Vous avez tout à fait raison, je l'ai trouvé maintenant et je ne sais pas comment je l'ai raté auparavant. Merci.

Je voudrais savoir si les API dont la case est cochée sont déjà implémentées ?

@akj "Ceux marqués comme terminés sont déjà pris en charge par le client REST de haut niveau, tandis que les autres doivent être ajoutés."

Salut tout le monde,
juste une petite question : l'UpdateSettingsRequest n'est-il pas censé implémenter également ToXContentObject, en plus de IndicesRequest.Replaceable ?

@javanna La liste des fonctionnalités à prendre en charge par le HLRC contient également ceci :

• mise à niveau (facile)
• statut de mise à niveau (facile)
  Cependant, la doc mentionne ceci :

L'API _upgrade n'est plus utile et sera supprimée. À la place, consultez Réindexer avant la mise à niveau.

La question est, les voulons-nous toujours et ils sont à gagner, ou dois-je chercher du travail ailleurs ? : RÉ

bon point @hariso , je vais déplacer ces deux API, je ne pense pas que nous devrions les implémenter pour le moment.

J'ai récupéré Cluster Health. Si quelqu'un d'autre travaille déjà dessus, veuillez m'en informer.

Je prends "mise à jour par requête".

La mise à jour par requête, la réindexation et la suppression par requête m'inquiètent car elles sont assez "étranges" dans leur façon de fonctionner. Je les ai écrits comme ça parce que ça avait du sens à l'époque mais je n'aime vraiment pas ça maintenant. Je suis d'accord pour les déplacer tels quels, mais j'aimerais les retravailler pour qu'ils soient moins déroutants un jour.

J'ai à peine commencé le travail, donc si vous (et @javanna je suppose) pensez que nous devrions le reporter, je peux prendre autre chose.

J'ai à peine commencé le travail, donc si vous (et @javanna je suppose) pensez que nous devrions le reporter, je peux prendre autre chose.

Nan, je ne pense pas que ça vaille la peine de retarder son intégration pour le retravailler. Je pense qu'il serait peut-être bien qu'il soit déjà intégré avant de le retravailler pour être honnête. Comprenez juste que c'est un peu bizarre. Beaucoup bizarre.

Je prends l'API Cluster : lister les tâches et obtenir la tâche, car elles utilisent le même objet de requête.

@javanna @nik9000 Je suis confus en ce moment. ListTasksRequest et GetTaskRequest peuvent tous deux demander une tâche spécifique par identifiant. Mais dans le point de terminaison REST, ListTasksRequest ne peut pas être utilisé à cette fin. En avons-nous besoin pour prendre en charge la compatibilité descendante avec le client de transport et permettre à ListTasksRequest d'être utilisé pour la tâche par identifiant ou mieux ajouter une validation qui l'empêchera ?
Je peux créer presque zéro changement de relations publiques pour cette discussion si nécessaire.

En avons-nous besoin pour prendre en charge la compatibilité descendante avec le client de transport et permettre à ListTasksRequest d'être utilisé pour la tâche par identifiant ou mieux ajouter une validation qui l'empêchera ?

@Van0SS Je ne le permettrais pas, sinon, dans certains cas, nous

Retour sur la migration d'un client 2.x vers 6.x. La seule chose qui ne s'est pas bien passée, ce sont les éléments du modèle admin().indices() et un étrange admin().validate().
Je ne sais pas si c'est destiné à voter, mais si c'est le cas, je voterais pour les fonctions du modèle ;)

merci pour vos retours @CodingFabian

Je vais chercher NodesInfo car il semble que ce soit la dernière des API importantes qui n'a pas été revendiquée.

@tvernum J'ai mis mon nom dessus (NodesInfo) hier et j'ai commencé une bonne quantité de travail dessus, il y avait déjà mon nom dessus mais je pense que vous n'avez peut-être pas rafraîchi parce que vous avez écrasé mon travail dessus

@dnhatn @jtibshirani (et autres)
Pouvez-vous vous assurer d'actualiser la page avant de modifier la description - il semble que la réclamation de NodesInfo ait à nouveau été perdue (comme la mienne) et d'après l'historique des modifications, il semblerait que l'un des vous l'avez peut-être fait accidentellement.

Attention : j'ai mis à jour la description de ce problème et réorganisé la liste des API en fonction des discussions récentes.

Je n'ai pas pu mapper l'API de repos de haut niveau avec Filter Query , quelqu'un peut-il m'indiquer la bonne direction.

@hth, veuillez poser vos questions sur nos forums à l' adresse https://discuss.elastic.co/

Salut, je travaille sur expliquer l'api car il n'est pas encore récupéré, je poste ici juste pour éviter les doublons.

merci de nous avoir fait savoir @PnPie et surtout d'avoir pris une autre API ! dans l'attente de votre RP.

Bonjour, Il semble que put stored script n'ait pas encore été choisi. Puis-je essayer de travailler sur cette API ?

bien sûr @johnny94 vas-y !

Salut @javanna
y a-t-il un accord pour ajouter un support pour le document _count ? Si c'est le cas, je peux travailler dessus.

@mrdjen Je pense que ce serait bien que @mrdjen se sente libre d'aller de l'avant et de le prendre. Ce serait un peu différent par rapport à d'autres API pour lesquelles nous avons déjà ajouté la prise en charge car elle n'a pas d'objets de demande et de réponse dans le code côté serveur, nous devons donc les ajouter directement au client.

Salut @nik9000 @hariso Je lisais la conversation sur le cas de "mise à jour par requête" de mars, avez-vous des nouvelles à ce sujet ? Cet ajout est-il toujours sur la table ou a-t-il été rejeté ? Je viens de réaliser que cela ne fait pas partie du client de haut niveau, quelle est votre suggestion pour trouver une solution de contournement pour cette API ? Je pense que je vais devoir utiliser le TransportClient à la place. Merci!

Salut @nik9000 @hariso Je lisais la conversation sur le cas de "mise à jour par requête" de mars, avez-vous des nouvelles à ce sujet ? Cet ajout est-il toujours sur la table ou a-t-il été rejeté ? Je viens de réaliser que cela ne fait pas partie du client de haut niveau, quelle est votre suggestion pour trouver une solution de contournement pour cette API ? Je pense que je vais devoir utiliser le TransportClient à la place. Merci!

Je fais! @sohaibiftikhar a commencé à envisager de mettre en œuvre la réindexation, la mise à jour par requête et la suppression par requête. Ils viennent en quelque sorte comme un paquet.

Personnellement, j'utiliserais le client de repos de bas niveau pour contourner le client de haut niveau qui ne prend pas en charge la mise à jour par requête pour le moment. Cela continuera à fonctionner pendant longtemps. Le client du transport mourra un jour. En outre, il est assez complexe de conserver un client de transport uniquement pour une ou deux API et d'utiliser REST pour les autres.

@sescotti @nik9000 Malheureusement, je n'ai pas encore eu le temps d'examiner la mise à jour par requête. : /

salut, @javanna
dans mon travail lorsque j'utilise ce client, j'ai rencontré quelques difficultés, je veux le journal de la réponse du serveur es, juste le journal dans le code ci-dessous, je veux qu'il supporte MDC. mais je ne trouve pas le chemin.

est dans le org.elasticsearch.client.RestClient

    private void performRequestAsync(final long startTime, final HostTuple<Iterator<HttpHost>> hostTuple, final HttpRequestBase request,
                                     final Set<Integer> ignoreErrorCodes,
                                     final HttpAsyncResponseConsumerFactory httpAsyncResponseConsumerFactory,
                                     final FailureTrackingResponseListener listener) {
        final HttpHost host = hostTuple.hosts.next();
       ...
        client.execute(requestProducer, asyncResponseConsumer, context, new FutureCallback<HttpResponse>() {
            <strong i="9">@Override</strong>
            public void completed(HttpResponse httpResponse) {
                try {
                    RequestLogger.logResponse(logger, request, host, httpResponse);//   i want the log of this  with MDC 
                 ........
                } catch(Exception e) {
                    listener.onDefinitiveFailure(e);
                }
            }

j'utilise slf4j + logback et je veux que le code comme celui-ci prenne en charge slf4-MDC

  String sessionId = MDC.get("SessionId");//get sessionID from current thread 
  client.execute(requestProducer, asyncResponseConsumer, context, new FutureCallback<HttpResponse>() {
            <strong i="13">@Override</strong>
            public void completed(HttpResponse httpResponse) {
                try {
                  MDC.put("SessionId", sessionId);  // put the sessionId to the thread-pool thread so that logback logger can find it .
                    RequestLogger.logResponse(logger, request, host, httpResponse);//   i want the log of this  with MDC 
                 ........
                } catch(Exception e) {
                    listener.onDefinitiveFailure(e);
                }
            }

la façon dont j'utilise le client

créer:

    <strong i="18">@Bean</strong>
    public RestHighLevelClient esOriginClient() {
        List<String> hostList = Arrays.asList(host.split(","));
        HttpHost[] httpHosts = new HttpHost[hostList.size()];
        for (int i = 0; i < hostList.size(); i++) {
            httpHosts[i] = new HttpHost(hostList.get(i), port, "http");
        }
        RestClientBuilder builder = RestClient.builder(httpHosts);
        return new RestHighLevelClient(builder);
    }

utilisation:

 SearchResponse searchResponse = client.search(request);

juste la méthode dans org.elasticsearch.client.RestHighLevelClient

  public final SearchResponse search(SearchRequest searchRequest, Header... headers) throws IOException {
        return performRequestAndParseEntity(searchRequest, Request::search, SearchResponse::fromXContent, emptySet(), headers);
    }

la façon dont j'ai essayé de soutenir mdc

1. myRestClient étend RestClient mais je trouve que le RestClient ne peut pas être étendu car le constructeur n'est pas public
2. J'essaie d'étendre org.elasticsearch.client.RequestLogger mais je trouve que c'est final et que la méthode est également statique.

donc je veux y a-t-il un moyen de m'aider? Désolée de vous déranger .

Salut @chenchuangc ! J'ai répondu au nouveau problème que vous avez déposé.

salut @nik9000 @hariso , je l'ai finalement trié à l'aide d'une recherche par défilement et d'une mise à jour en masse (après avoir essayé d'utiliser la mise à jour par requête, j'ai découvert qu'il n'était pas possible d'envoyer des mises à jour partielles, ce qui est mon exigence ici). Merci quand même!

Le client de haut niveau REST ne peut pas être utilisé par bulkprocessor, veuillez ajouter cette api

@iamazy BulkProcessor est pris en charge, voir https://www.elastic.co/guide/en/elasticsearch/client/java-rest/current/java-rest-high-document-bulk.html#java -rest-high-document -bulk-processor .

ajouterait-il l'API bucket_script ?

@javanna J'avais essayé le client au repos de haut niveau avec bulkprocessor, mais j'ai eu quelques erreurs, le client est l'instance de TransportClient et non l'instance du client de haut niveau-reste, existe-t-il une autre classe nommée bulkprocessor ?

@iamazy les documents que j'ai liés ci-dessus sont pour le client REST de haut niveau. La classe BulkProcessor reste la même, mais elle accepte une fonction comme argument qui identifie la méthode client en bloc à appeler. Je soupçonne que vous utilisez une ancienne version si vous ne voyez pas la même chose.

@javanna Savez-vous quelle version d'Elasticsearch ciblez DeleteByQuery et UpdateByQuery ? Je vois que ces API sont déjà implémentées sur un dev fork et que la demande de révision est en attente de fusion. Avez-vous un échéancier quant au moment où ces API feront partie du client officiel Elastisearch High REST et de quelle version ?

Des projets de portage sur DeleteByQueryRequestBuilder ?

J'ai commencé à regarder "get task" (êtes-vous allé quelque part avec ce
Un point d'incertitude est la politique générale de HLRC pour la traduction des GET /foo 404 en langage Java. Les options sont :
1) getFoo lève une exception
2) getFoo renvoie null
3) getFoo renvoie un objet FooResponse qui a une propriété "isExists()" pour dire s'il est rempli

L'option 3 semble un peu étrange aux développeurs Java, mais je vois que c'est ce que nous faisons pour les documents avec la classe GetResponse.java.

@markharwood pas grand chose, vous pouvez assumer cette tâche, @javanna pourriez-vous me retirer s'il vous plaît de la liste assignée ? Désolé si j'ai demandé à quelqu'un de commencer à travailler dessus.

Un point d'incertitude est la politique générale de HLRC pour la traduction des GET /foo 404 en langage Java.

Oui. Je ne sais pas quelle est la bonne méthode, mais je ne pense pas que isExists() soit.

Mes 2 cents : en tant qu'utilisateur de la bibliothèque cliente, je préfère ne pas avoir à détecter une exception pour une situation telle qu'une entité introuvable. Ce n'est pas vraiment une situation exceptionnelle, rien d'extraordinaire. Devoir essayer-attraper pour gérer une telle situation rend le code client plus laid que nécessaire. D'un autre côté, de nombreux pilotes de base de données renvoient simplement une valeur null ou une option facultative lorsque rien n'est trouvé.

im ++ pour ne pas lancer d'exceptions aussi. J'ai fait un échantillonnage aléatoire de 4 choses qui lancent des 404 sur le serveur s'ils ne sont pas trouvés, et les résultats sont presque tous qu'ils ont une méthode "existe" de quelque sorte. L'alias est juste un peu différent en raison de son API. Je suis sûr qu'il y a des cas où nous levons une exception, mais il semble que nous ne devrions pas le faire.

Il existe un concept de StatusToXContentObject qui renvoie un RestStatus au consommateur. Nous n'avons actuellement aucune norme sur « quel était le statut de l'appel que j'ai passé » dans la base de code, il pourrait donc être judicieux d'en ajouter une. Je tiens à ajouter quelque chose aux réponses pour cela. Nous avons environ 15 réponses qui sont des StatusToXContentObject , et le volume/index en fait partie. Ceux-ci reposent toujours sur 1) le statut enregistré dans les réponses, ou 2) un booléen utilisé pour dire si c'est OK ou NOT_FOUND. Ce dernier est la façon dont get pipelines le fait. Le premier est ce qui est stocké dans la réponse get aliases.

Je n'aime pas la réponse nulle. Je préférerais que quelqu'un fasse un if (vérification du statut) par rapport à if (vérification nulle), mais cela pourrait être à cause de mes jours de scala. Je pense qu'un facultatif fonctionnerait également si nous voulons devenir un peu fonctionnels, comme le mentionne @hariso :)

Mon .02 serait d'avoir soit un moyen de dire "isFound" tel que traduit par un code d'état interne, ou simplement d'enregistrer le code d'état du reste en interne et de laisser l'utilisateur raisonner à ce sujet. Le premier garantit que nous pouvons dire "Eh bien, ce code de statut non 200 est en fait" ok "", mais je ne sais pas si nous avons une raison pour cela. ce dernier donne à l'utilisateur la souplesse et le pied pistolet. Je serais également très bien avec un facultatif.

Les méthodes que j'ai vérifiées

Alias - getAlias has a getException() which is validated against if there are any exceptions in the call.
Pipelines - get pipeline response is a StatusToXContentObject
Get - 404 if index not found, isExists (which is a bool set on the GetResult nested in the response set by ShardService) if doc not found
Delete watch - isFound, which is set directly by the transport action

@hub-cap Un de plus pour la liste - l'API Explain utilise également l'approche "isExists".

Cela semble être l'endroit où le choix de conception "isExists ou exception" est forcé. Le paramètre ignores peut être utilisé pour déclarer que 404 codes d'état sont à prévoir, mais la logique de cette méthode d'assistance utilise la même méthode responseConvertor.apply pour analyser à la fois les réponses saines et les codes d'erreur "ignorés" - le même type d'objet de réponse est renvoyé. Cela nous oriente vers l'utilisation d'un objet "FooResponse" avec une propriété "isExists" quelconque.
L'utilisation alternative de cette méthode consiste à appeler sans lister les 404 dans le paramètre ignores , auquel cas une exception plus générique est levée (ElasticsearchStatusException avec le statut =404).

Peut-être une autre "convention Java" générale à considérer @hub-cap.

Comment mapper les API REST de style wait_for_completion=false potentiellement de longue durée à notre notion d'appels Java sync et asynchrones ?

J'ai appuyé sur ceci en essayant de trouver une tâche de longue durée qui pourrait être utilisée dans mes tests getTask . Il semble que le reindex HLRC ait été écrit sans aucun support pour renvoyer les ID de tâche. Cela signifie que reindex et getTask ne peuvent pratiquement pas être utilisés ensemble dans HLRC. Reindex doit trouver un moyen d'offrir davantage de fonctionnalités asynchrones.
Lors de discussions avec @pgomulka, nous avons proposé cette convention générale candidate pour mapper les API REST asynchrones sur Java :

• Foo syncFoo(...) et void asyncFoo(..., listener) correspondraient aux appels REST _sans_ wait_for_completion params (la majorité de nos API existantes)
• FooTask submitFooTask(...) correspondrait aux équivalents REST avec wait_for_completion défini sur false. C'est un appel synchrone à une API REST avec des fonctionnalités asynchrones.

Est-ce que ça a du sens? Cela s'applique probablement à plus de reindex

@markharwood Je pense que, comme mentionné ci-dessus, je ne pense pas que le lancement d'exceptions soit la voie à suivre, donc je ne pense pas que nous devrions le supprimer de ignores . Juste pour réitérer le travail que j'ai vu dans votre autre critique, #35166, je pense que l'utilisation de Optional fonctionne bien ici.

De plus, je suis d'accord avec @pgomulka et votre évaluation de sync/async/submit, :shipit:

La mise à jour d'elastic vers 5.x à partir de 2.x nécessite que la sécurité du bouclier soit remplacée par la sécurité x-pack et le client de transport java avec le client java Rest-High-Level/Low-Level-Client.
Où puis-je trouver les informations sur l'utilisation de xpack avec le client de repos java Elasticsearch pour la version 5.6.2 et si aucune de ces informations n'est présente, comment puis-je le faire ? Aide svp :)

@utkarsh4G Pourriez-vous s'il vous plaît poser cette question sur notre forum de discussion
Elastic utilise les problèmes GitHub pour suivre les travaux à entreprendre, tels que les bogues et les demandes de fonctionnalités, et nous utilisons les forums pour des questions telles que les vôtres.

Clôture en faveur du #47679

Je plaisante, je ferme en faveur de #47678