Elasticsearch: Ajouter un moyen de déterminer la position d'un résultat dans un ensemble ou la présence de résultats avant/arrière
Décrivez la fonctionnalité :
Le nouveau paramètre search_after est génial pour parcourir d'énormes ensembles de résultats ! J'essaie de connecter ElasticSearch à une API GraphQL à l'aide de la spécification de connexion Relay, et je rencontre un problème où je ne parviens pas à déterminer s'il existe des résultats supplémentaires avant ou après l'ensemble actuel. Je peux contourner le problème pour le moment en récupérant un résultat de plus que ce dont j'ai besoin à l'arrière de l'ensemble, puis en exécutant une autre requête pour un seul résultat avant l'ensemble (en inversant l'ordre). Cela semble maladroit cependant. Est-il possible d'obtenir un moyen de déterminer la présence d'enregistrements avant et arrière ou de déterminer la position de l'ensemble actuel dans le résultat global ? Je vois que cela est une exigence pour de nombreux cas d'utilisation.
rbayliss
Tous les 3 commentaires
Compte tenu de la façon dont les choses sont implémentées, nous pourrions théoriquement compter le nombre de documents que nous ignorons en raison du fait que la comparaison est inférieure aux valeurs de tri fournies dans search_after . Cependant, cela signifie mettre à jour les réponses à l'API de recherche pour inclure ces informations, modifier les collecteurs Lucene pour exposer ce décalage et plus généralement propager ces informations du collecteur jusqu'à la réponse de recherche, de sorte que ce ne serait pas un changement trivial. Je suggère que nous gardions cette question ouverte pendant un certain temps afin de mesurer l'intérêt qu'elle suscite.
jpountz
le 29 déc. 2016
cc @elastic/es-search-aggs
mayya-sharipova
le 22 mars 2018
Étant donné que nous n'avons pas vu beaucoup d'intérêt pour ce problème, et parce qu'il nécessitera beaucoup de modifications, et qu'il existe une solution de contournement à partir de la taille du client, je ferme ce problème.
mayya-sharipova
le 21 mai 2018
Questions connexes
ttaranov
·
3Commentaires
clintongormley
·
3Commentaires
martijnvg
·
3Commentaires
mayyamus
·
3Commentaires
dawi
·
3Commentaires
Commentaire le plus utile
Compte tenu de la façon dont les choses sont implémentées, nous pourrions théoriquement compter le nombre de documents que nous ignorons en raison du fait que la comparaison est inférieure aux valeurs de tri fournies dans
search_after. Cependant, cela signifie mettre à jour les réponses à l'API de recherche pour inclure ces informations, modifier les collecteurs Lucene pour exposer ce décalage et plus généralement propager ces informations du collecteur jusqu'à la réponse de recherche, de sorte que ce ne serait pas un changement trivial. Je suggère que nous gardions cette question ouverte pendant un certain temps afin de mesurer l'intérêt qu'elle suscite.