Actuellement, la recherche dans la liste de membres s'effectue avec la clause SQL COLLATE NOCASE
et avec une collation spécifique qui remplace celle de SQLite. De même pour la clause "LIKE".
Utiliser cette collation / LIKE spécifique permet de faire des recherches pour que "emilie" renvoie "émilie" et "Émilie".
Problèmes de cette approche :
- cela fait appeler un callback PHP à chaque comparaison de ligne dans la table, plus lourd que SQLite nativement donc
- "émilie" ne devrait pas être égal à "emilie" dans tous les cas
- cela peut rendre un index unique non-unique, occasionnant des bugs
- divers problèmes de performance, car le LIKE utilise alors preg_match
- il se peut qu'il manque des entrées dans l'index, occasionnant des problèmes de base corrompue (database disk image is corrupted), exemple :
row 401 missing from index users_list_prenom
row 447 missing from index users_list_prenom
row 466 missing from index users_list_prenom
row 467 missing from index users_list_prenom
row 468 missing from index users_list_prenom
row 480 missing from index users_list_prenom
row 489 missing from index users_list_prenom
row 509 missing from index users_list_prenom
wrong # of entries in index users_list_ville
wrong # of entries in index users_list_nom
Il faudrait donc :
- dupliquer toutes les colonnes de type TEXT de la table membre, par exemple
nom
serait dupliqué sous le nom nom_searchable
- cette colonne dupliquée contiendrait la valeur en minuscules, et sans accents, normalisée, pour recherche avec le critère
COLLATE NOCASE
- ne plus "overrider" la collation
NOCASE
ni la fonction LIKE
de SQLite