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
