Produits Entr'ouvert » Authentic 2

• si un uuid, un téléphone, un nom d'utilisateur ou un email est donné, on utilise le trie par défaut
• si on passe en recherche par trigramme via find_duplicates alors on trie par le pourcentage de correspondance et rien d'autre
• si aucun des ces recherches spécifiques ne retourne de résultat on retourne sur l'ancien code (on cherche partout dans tous les attributs) et on trie par défaut

Pour ce qui est de l'email et de la date de naissance pas de pb, par contre la suite pose question, quelqu'un qui habite rue Deshayes va sortir dans la recherche jusqu'à ce qu'un Mr Deshayes se crée un compte, c'est un comportement bizarre.

En fait pour email ou date on a une manière suffisamment fiable pour déterminer ce que l'agent recherche, en revanche on ne sait pas distinguer un nom d'une adresse ou autre attribut texte. Pour moi ce serait mieux que find_duplicates intervienne dans free_text_search_complex plutôt qu'à la place (avec éventuellement en bonus un tri qui fasse ressortir les gens retournés par find_duplicates avant ceux dont un attribut matche).

Valentin Deniaud a écrit :

En fait pour email ou date on a une manière suffisamment fiable pour déterminer ce que l'agent recherche, en revanche on ne sait pas distinguer un nom d'une adresse ou autre attribut texte. Pour moi ce serait mieux que find_duplicates intervienne dans free_text_search_complex plutôt qu'à la place (avec éventuellement en bonus un tri qui fasse ressortir les gens retournés par find_duplicates avant ceux dont un attribut matche).

Je ne sais pas faire cela, on peut trier par distance et rechercher par trigramme ou chercher librement dans tous les attributs, on ne peut pas faire les deux. Je serai plutôt pour abandonner la recherche libre sur les attributs dans ce cas là, en vrai on a nulle part de recherche sur l'adresse. Les gens recherchent par nom , téléphone ou email.

Benjamin Dauvergne a écrit :

Je serai plutôt pour abandonner la recherche libre sur les attributs dans ce cas là, en vrai on a nulle part de recherche sur l'adresse. Les gens recherchent par nom , téléphone ou email.

Si ça ne sert à rien c'est bien de l'enlever, mais tu écrivais

J'ai conservé l'ancienne implémentation en dernier recours, des endroits peuvent en dépendendre (identifiant RSA ou que sais-je).

Au pire un setting qui désactive le recours à free_text_search_complex par défaut, pour pouvoir le remettre vite si quelqu'un crie, et l'enlever sereinement au cycle d'après sinon ?

(c'est rouge)

Malheureusement l'union qs1 | qs2 n'utilise plus l'index trigram, donc cette approche n'est pas la bonne...

(j'ai vu ça en utilisant la méthode explain(), puis pour confirmer j'ai utilisé la fixture large_userbase et rajouté 100 itérations dans test_fts_legacy_and_trigram, résultat j'ai un run à 3s avec juste qs1, un autre à 70s avec l'union)