Elasticsearch et hibernate search sont sur un bateau

Ou se battent pour le gouvernail.

Bonjour,
Excusez moi pour ce sujet accrocheur, mais je ne trouve pas grand monde pour m'aider dans mon soucis. J'ai vu cette video elasticserch et hibernatesearch sont sur un bateau. https://www.youtube.com/watch?v=pQJY-Mu-yGA&t=1585s

Le travail effectué par l'équipe hibernate a grandement simplifier l'indexation transparente d'une entité hibernate (totale ou partiel avec les annotation hibernate search). Je travail actuellement sur un projet où j'utilise ce backend pour indexer des informations sur un serveur elasticsearch, la remonté fonctionne parfaitement pour en faire de la recherche full text, il y a un autre sujet c'est qu'il faille extraire des statistiques des ces données indexées sur mon projet. Donc pour ce faire j'ai ajouté l'API 5.6.8 HighRestApiClient d'elastic pour faire mes agrégations, somme et graphs et la c'est la foire au conflit java, en cause : Lucène.

Ma première tentative de résolution à été de supprimer toutes les dépendance à Lucene du package elasticsearch server pour pouvoir utiliser l'api Rest. Dans cette tentative j'ai du récupérer la class Version de Lucene (org.lucene.utils pour le package, je n'ai pas le nom exact en tête) pour l'incorporé à mon projet, depuis cela j'ai pu utiliser l'API et compiler mon projet. mais il reste de l'adhérence a une version de Lucene lorsque je veut utiliser liquibase (gestion de migration de donnée incrémentale) lorsqu'il veut instantier hibernatesearch. Pour contourné le problème et faire mes migrations je suis obligé de commenter tout ce qui est en rapport avec l'API Rest High client, faire la migration et revenir en arrière pour que tout se passe bien. Dans un projet industriel, ce n'est pas une bonne pratique.

Stack d'erreur obtenu : Exception in thread "main" java.util.ServiceConfigurationError: An SPI class of type org.apache.lucene.codecs.PostingsFormat with classname org.apache.lucene.search.suggest.document.Completion50Postin
gsFormat does not exist, please fix the file 'META-INF/services/org.apache.lucene.codecs.PostingsFormat' in your classpath.
at org.apache.lucene.util.SPIClassIterator.next(SPIClassIterator.java:160)
at org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:70)
at org.apache.lucene.util.NamedSPILoader.(NamedSPILoader.java:51)
at org.apache.lucene.util.NamedSPILoader.(NamedSPILoader.java:38)
at org.apache.lucene.codecs.PostingsFormat$Holder.(PostingsFormat.java:49)
at org.apache.lucene.codecs.PostingsFormat.forName(PostingsFormat.java:112)
at org.apache.lucene.codecs.lucene54.Lucene54Codec.(Lucene54Codec.java:161)
at org.apache.lucene.codecs.lucene54.Lucene54Codec.(Lucene54Codec.java:81)

Ma question est plus une demande, car lorsque je regarde le code source sur github de l'api rest client fournit par elastic, j'ai l'impression que l'on a besoin du server pour les objet qui sont sérialisés et qui servent a créer les JSON envoyé ou reçu de la part du serveur. Pourquoi à ton besoin de l'ensemble du serveur et donc Lucene pour pouvoir juste communiqué avec lui via JSON et du REST ???

Est ce qu'elastic à l'avenir ne peux pas externalisé dans un package indépendant les objets utils à la communication entre API Rest et Serveur + serialisation / déserialisation, et être réutilisé par le serveur et l'api REST, comme cela plus de soucis de conflit et d'adhérence avec Lucene ?

Je suis dans l'impasse je vous l'avoue car soit je vais être obliger de récupérer l'intégralité des source github pour récupérer et compiler une API rest custom pour plus avoir d'adhérence à Lucene, soit de recoder tout ce que me fournit hibernate search elasticsearch backend. Alors que les deux ensemble réglerait pas mal de chose et permettrait de faire encore plus de chose.

Alexis

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.

Désolé pour le délai.

D'abord j'espère que nos uniformes de marins nous allaient encore... :slight_smile:

Comme je l'ai dit sur Hibernate search + elastics search are on the same boat, but this boat flow ce n'est pas si simple mais c'est vraiment en bonne voie. Il y a encore eu des PR mergées très récemment qui enlèvent encore plus cette adhérence...

Pas de promesses mais c'est en bonne voie...

Re bonjour david,
Je vous avez contacter par mail, et vous m'aviez rediriger sur ce forum. J'ai bien compris que c'était dans le pipe d'elastic de se défaire au maximum de la dépendance à Lucene. J'espère que dans un avenir proche une version des clients elastic sera disponible sans avoir ces dépendances à Lucene et éviter ces conflits. Pour le moment je me suis bricoler un ensemble de Class redéfinissant les requêtes ES dont j'ai besoin et avec Jackson je sérialise à la volé et j'envoie ma requête avec l'api basse. la de-sérialisation pareil. Mais j'avoue que ca me fait produire pas mal de code. Ca demandera du refactoring plus tard.
PS : les costumes allaient encore bien.

1 Like