normalizer les numéros de téléphone dans l'index FTS (#76875) #259
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/76875-Recherche-par-numero-de-telephon"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
ac6c80a1ea
tod94a0f0379
WIP: normalizer les numéros de téléphone dans l'index FTS (#76875)to normalizer les numéros de téléphone dans l'index FTS (#76875)C'est à rebaser (la partie FtsMatch à déplacer dans le nouveau sql_criterias.py) ; mais le code me semble tout bon.
d94a0f0379
tob26b7e407a
b26b7e407a
to8dc1fe99af
@ -2621,1 +2621,4 @@
fts_strings[weight].add(value)
# special case telephone numbers
if value != normalize_phone_number_for_fts_if_needed(value):
fts_strings[weight].add(normalize_phone_number_for_fts_if_needed(value))
Ça m'irait bien d'ajouter à la comparaison un truc genre len(value) < 30, limiter le nombre de fois où on passe là-dedans.
Comme on peut encore commenter un peu, à la rerelecture je me dis qu'on devrait poser ça en priorité "D" (
fts_strings['D'].add(...)
) pour permettre de prioriser les numéros de téléphones officiels (les champs avec validation téléphonique).Au doigt mouillé je n'ai pas l'impression qu'un len(value) < 30 changera énormément le nombre d'appels, même un len(value) < 15 (10 chiffres plus des séparateurs entre groupe de deux) ça prendra je pense la plupart des tokens.
Ça par contre ça ne me semble pas poser de souci oui.
Un < 15 m'irait aussi, je tapais juste large. (mon truc étant d'éviter d'envoyer les adresses, les champs commentaires libres, etc. vers la fonction qui va jouer deux regex dessus.
Je retire ce que je dis, c'est la valeur du champ complet qui est traité, je pensais qu'on faisait un split() avant. Ok, donc.
quelques commentaires finalement
8dc1fe99af
tob6af61ab33