elastic/elasticsearch

Consistency between `_search` and `_msearch`

Open

#4.227 aberto em 21 de nov. de 2013

Ver no GitHub
 (42 comments) (1 reaction) (0 assignees)Java (25.882 forks)batch import
:Search Foundations/Search>bugTeam:Search Foundationsgood first issuehelp wantedpriority:normal

Métricas do repositório

Stars
 (76.700 stars)
Métricas de merge de PR
 (Mesclagem média 2d) (1.000 fundiu PRs em 30d)

Description

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.

Guia do colaborador

Direção de pesquisa
O problema é garantir que a API msearch aceite os mesmos parâmetros de cabeçalho que os parâmetros de consulta do search. A solução proposta é modificar MultiSearchRequest.add() para usar RestSearchAction.parseSearchSource() ou parseSearchRequest() para analisar sub solicitações. Comece examinando a implementação atual de MultiSearchRequest.add() na base de código do Elasticsearch e estude como o RestSearchAction lida com parâmetros de consulta como 'version'. Veja os comentários vinculados para discussões sobre o comportamento desejado. Em seguida, implemente as alterações para delegar a análise adequadamente, garantindo compatibilidade com versões anteriores.
Pilha de tecnologia
java
Domain
backend
Tipo Issue
Bug
DifficultyDificuldade de implementação estimada para um novo contribuidor, de 1 para alterações muito pequenas a 5 para trabalho de nível especializado.
2
Tempo estimadoUm intervalo de tempo aproximado para um colaborador experiente investigar, implementar, testar e preparar um pull request.
1-3 horas
Status da atividadeQuão disponível o issue aparece agora: novo, ativo, obsoleto, bloqueado ou aguardando entrada do mantenedor.
Ativo
ClarityCom que clareza o issue explica a mudança esperada, os critérios de aceitação e a próxima etapa.
Principalmente claro
Prerequisites
Git
Simpatia para novatosUma pontuação de 1 a 100 que estima o quão acessível este issue é para colaboradores iniciantes.
70