Aucun mappage trouvé pour le champ afin de sortinger dans ElasticSearch

Elasticsearch génère une SearchParseException lors de l’parsing syntaxique d’une requête si certains documents ne contiennent pas de champ utilisé dans les critères de sorting.

SearchParseException: Échec d’parsing [Aucun mappage trouvé pour [prix] afin de sortinger sur]

Comment puis-je rechercher ces documents avec succès, même si certains ne sont pas dans le champ de price ?

Après avoir creusé plus, j’ai trouvé la solution comme indiqué ci-dessous. ignore_unmapped doit être explicitement défini sur true dans la clause sort.

 "sort" : [ { "rating": {"order" : "desc" , "ignore_unmapped" : true} }, { "price": {"order" : "asc" , "missing" : "_last" , "ignore_unmapped" : true} } ] 

Pour plus d’informations, consultez les références Elasticsearch pour:

  • valeurs manquantes
  • ignorer les champs non mappés

Pour ceux qui recherchent un exemple à la fois ignore_unmapped et ignore_unmapped , veuillez consulter ma réponse ici .

Notez que “ignore_unmapped” est maintenant déconseillé en faveur de “unmapped_type”. Cela a été fait dans le cadre de # 7039

De la documentation: Avant la version 1.4.0, il y avait le paramètre booléen ignore_unmapped, qui ne suffisait pas pour décider des valeurs de sorting à émettre et ne fonctionnait pas pour la recherche d’index croisés. Il est toujours pris en charge mais les utilisateurs sont encouragés à migrer vers le nouveau unmapped_type à la place.

Par défaut, la requête de recherche échouera si aucun mappage n’est associé à un champ. L’option unmapped_type permet d’ignorer les champs sans mappage et de ne pas les sortinger. La valeur de ce paramètre est utilisée pour déterminer les valeurs de sorting à émettre. Voici un exemple d’utilisation possible:

 { "sort" : [ { "price" : {"unmapped_type" : "long"} }, ], "query" : { "term" : { "user" : "kimchy" } } } 

Si l’un des index interrogés ne possède pas de correspondance pour le prix, Elasticsearch le gérera comme s’il y avait un mappage de type long, tous les documents de cet index n’ayant aucune valeur pour ce champ.

Apparemment, ElasticSearch ne sortingera pas sur les valeurs nulles. Je supposais qu’il traiterait null comme étant au début ou à la fin (comme dans le cas de l’ordre SQL), mais je crois que cela déclenche également cette erreur.

Donc, si vous voyez cette erreur, vous devrez vous assurer que l’atsortingbut de sorting a une valeur par défaut lorsqu’il est envoyé à ElasticSearch.

J’ai eu cette erreur avec Rails + ElasticSearch + Tire parce que la colonne de sorting n’avait pas de valeur par défaut, elle était donc envoyée à ES en tant que null.

Ce problème indique que les valeurs NULL sont gérées, mais ce n’était pas mon expérience. C’est quelque chose qui mérite d’être essayé de toute façon.

J’ai rencontré le même problème (sorta; aurait des erreurs, mais des résultats), mais dans mon cas, ma recherche était émise à la racine (aucun index spécifié) et les erreurs que je recevais étaient dues au fait que la recherche / commande était également à la recherche d’un indice Kibana.

Erreur stupide, mais peut-être que cela aidera quelqu’un d’autre qui finira ici.