GPS: Amélioration de l'autocomplete

[tonial]

🤔 Pourquoi ?

Les performances sont clairement inférieures, mais au moins le résultat est exploitable.
La version actuelle ne sera à rien sur des noms ou prénom trop communs (trop de résultats possibles pour être sur que la personne que l'on cherche apparaisse dans les 10 premiers)

On ajoute le titre si on le connaît, ainsi que la date de naissance pour mieux gérer les homonymes.

Niveau performances : ~ 1.25 secondes par requete (c'est donc super long)

Une alternative est présente ici :#5365 en utilisant la recherche plein texte

🍰 Comment ?

Décrivez en quelques mots la solution retenue et mise en oeuvre, les difficultés ou problèmes rencontrés. Attirez l'attention sur les décisions d'architecture ou de conception importantes.

🚨 À vérifier

• Mettre à jour le CHANGELOG_breaking_changes.md ?

🏝️ Comment tester

Les instructions pour reproduire le problème, les profils de test, le parcours spécifique à utiliser, etc. Si vous disposez d'une recette jetable, mettre l'URL pour tester dans cette partie.

💻 Captures d'écran

[github-actions]

🥁 La recette jetable est prête ! 👉 Je veux tester cette PR !

[francoisfreitag]

On révèle maintenant encore plus d’informations avec ce endpoint, je ne sais pas si c’est OK point de vue juridique et sécu ?

[tonial]

ce sont des infos auxquelles on a accès une fois la personne ajoutée, donc pour moi cela ne change pas (le endpoint a les même restrictions d'usage que la vu de détail)

EDIT: j'ajoute le titre qui n'est en fait pas dans la page suivante, mais on y trouve le NIR dont le premier chiffre donne la même info en général :)

[francoisfreitag]

Je ne suis pas trop fan des perfs, ça impacte le service des emplois en général. Serait-il possible pour le métier de trouver quelques critères plus discriminants ? Genre département, civilité 🤷

[tonial]

Hum... c'est vrai que c'est un problème...
Peut être passer sur un formulaire avec une liste, et donc pas un autocomplete ?
un peut comme la recherche de l'admin

[xavfernandez]

Ça me semble bien violent avec autant de subqueries qu'il y a de termes 😱
Je pense qu'on doit pouvoir faire sans subqueries...

[tonial]

Si tu as une idée, je suis preneur !
Le truc c'est qu'afin de pouvoir mettre un score qui dépend du nombre de correspondances trouvées, ce sera forcément une subquery par terme, non ?

[xavfernandez]

         def match_term(term):
             return Cast(
-                Exists(
-                    User.objects.filter(pk=OuterRef("pk")).filter(
-                        Q(first_name__unaccent__icontains=term) | Q(last_name__unaccent__icontains=term)
-                    ),
-                ),
+                Q(first_name__unaccent__icontains=term) | Q(last_name__unaccent__icontains=term),
                 IntegerField(),
             )

semble aussi bien marcher 😌

[xavfernandez]

Après ça reste violent vu que postgres est obligé de regarder et trier tous les comptes candidats...

[xavfernandez]

Donc je pense que tu devrais également garder le filter(or_queries(name_q)) histoire que postgresql n'aie pas besoin systématiquement de traiter 1M+ de comptes à chaque requête 😬

[tonial]

C'est en effet beaucoup mieux, on passe de 3 à 2 secondes dans un cas de test, mais c'est pas suffisant pour le laisse en autocomplete dans cet état.

Le or_queries n'améliore pas grand chose. Je pense que l'élément coûteux c'est de rechercher chaque terme dans prénom et nom. Donc le faire pour filter et compter, ou uniquement pour compter c'est kif-kif.

Par contre, en forçant la présence du premier terme, ça limite pas mal l'impact en performances quand il y a plusieurs termes.

[tonial]

Et sinon, ts_vector de psql accepte un dictionnaire "simple" qui évite le stemming 🤩

Ce qui permet donc de laisser psql faire un truc plus optimisé niveau performances que ma première piste un peu à la mano

(voir la seconde PR )