elastic/elasticsearch

Consistency between `_search` and `_msearch`

Open

#4.227 geöffnet am 21. Nov. 2013

Auf GitHub ansehen
 (42 Kommentare) (1 Reaktion) (0 zugewiesene Personen)Java (25.882 Forks)batch import
:Search Foundations/Search>bugTeam:Search Foundationsgood first issuehelp wantedpriority:normal

Repository-Metriken

Stars
 (76.700 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 2T) (1.000 gemergte PRs in 30 T)

Beschreibung

The _msearch API doesn't accept the same header parameters than _search's query parameters. For instance version is both valid in the search body and query parameters for _search, but is ignored in the query parameters and header in _msearch.

MultiSearchRequest.add() should rely on RestSearchAction.parseSearchSource() or even RestSearchAction.parseSearchRequest() to parse the subrequests, for maximum compatibility.

IMHO, a clean bulk API should use the header parameters as query parameters on the target endpoint, which would imply that they keep in sync no matter the code changes in the target endpoints.

Contributor Guide

Research-Richtung
Das Problem betrifft die Sicherstellung, dass die msearch API dieselben Header Parameter wie die Abfrageparameter von search akzeptiert. Der vorgeschlagene Lösungsansatz besteht darin, MultiSearchRequest.add() so zu ändern, dass es RestSearchAction.parseSearchSource() oder parseSearchRequest() zum Parsen von Teilanfragen verwendet. Beginnen Sie mit der Untersuchung der aktuellen Implementierung von MultiSearchRequest.add() in der Elasticsearch Codebasis und studieren Sie, wie RestSearchAction Abfrageparameter wie 'version' verarbeitet. Sehen Sie sich die verlinkten Kommentare für Diskussionen zum gewünschten Verhalten an. Implementieren Sie dann die Änderungen, um das Parsing entsprechend zu delegieren, wobei die Abwärtskompatibilität sichergestellt werden muss.
Tech Stack
java
Domain
backend
Issue Type
Fehler
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
2
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
1-3 Stunden
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Meist klar
Voraussetzungen
Git
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
70