Bonjour François,
Merci beaucoup pour ton retour.
Le contournement appliqué dans notre contexte spécifique MySQL est pour l’instant déployé et fonctionnel tel que avec ses avantages et ses défauts.
J’ai commencé à tester les modalités de recherches fulltext offertes par PostGreSQL (qui est la brique SGBD déployée en standard dans nos architectures) et il y a là aussi des subtilités que je commence à fouiller (source : PostgreSQL: Documentation: 15: 12.3. Controlling Text Search).
En particulier, je vois dans la documentation et en testant que l’opérateur ‘-’ n’est pas supporté/interprété par la couche tsquery mais que la fonction websearch_to_tsquery le supporte (de manière simplifiée telle que je le comprends, en substituant ‘-’ par ‘!’).
En testant, j’ai l’impression que la recherche globale Simplicité traite correctement la négation de terme avec ‘!’ mais ignore l’opérateur ‘-’. Ce qui semble indiquer que de manière sous-jacente le runtime “pousse” les termes saisis par l’utilisateur en tant que tsquery et n’exploite pas le service proposé de traduction websearch_to_tsquery… Pour autant, si je saisi des termes en mode tsquery ça ne ramène plus rien…
-
+service +nissan +dacia -etuderamène ce qui est indexé avec service, nissan et dacia mais ramène aussi les études (le ‘-’ est ignoré) -
+service +nissan +dacia !etuderamène ce qui est indexé avec service, nissan et dacia mais pas les études (ce qui est attendu) -
'service' & 'nissan' & 'dacia' & !'etude'(search en mode tsquery natif) ne ramène rien
J’ai donc l’impression que nous sommes entre les deux modes websearch (très simple et accessible) et tsquery (très puissant et formel).
→ Simplicité fait-il quelque-chose sur les termes avant de les pousser à PostGreSQL ?
Autre différence de comportement, avec PostGreSQL, il semble que l’opérateur ‘*’ ne soit pas nécessaire pour étendre les termes (gloss* pour couvrir gloss, glossary, glossaire, etc…). Le fait de mettre ‘*’ ou pas est traité de manière apparemment identique.