Eric a écrit:

Code:

SELECT username
FROM '.USERS_TABLE.'
WHERE '.LCAS_change_case(.'username'.).' LIKE '.$_post($username).';

Si on choisit l'option insensible aux accents... ça va générer une sacré matrice...

Exemple :
Mémé...
Meme, Méme, MeMé, Mêmé, Mèmë, .....

Ce serait plutôt un IN qu'un LIKE... mais il y aura un potentiel gros tableau...

Whiler a écrit:

Eric a écrit:

Code:

SELECT username
FROM '.USERS_TABLE.'
WHERE '.LCAS_change_case(.'username'.).' LIKE '.$_post($username).';

Si on choisit l'option insensible aux accents... ça va générer une sacré matrice...

Exemple :
Mémé...
Meme, Méme, MeMé, Mêmé, Mèmë, .....

Ce serait plutôt un IN qu'un LIKE... mais il y aura un potentiel gros tableau...

??

Le SELECT est effectué sur username, donc ne peuvent sortir que les username inscrits dans la galerie ? S'il y a "Mémé" et "Mèmë", ils vont sortir tous les deux, mais pas "Meme", "Méme", "MeMé", et "Mêmé" (et tous les autres), non ? Me planté-je ?

LucMorizur a écrit:

On peut donc a priori faire fonctionner LCAS même avec l'extension mbstring non chargée !

A priori, ce n'est plus a priori ;-) !

[Subversion] r9499

Whiler a écrit:

LucMorizur a écrit:

Génial !

ne parle pas de moi comme ça.. ça me rend mal à l'aise ;o))

Je te comprends : ça me fait pareil...........

Sauf que... moi, on ne me le dit jamais :'-(( .........

Whiler a écrit:

LucMorizur a écrit:

Le SELECT est effectué sur username, donc ne peuvent sortir que les username inscrits dans la galerie ? S'il y a "Mémé" et "Mèmë", ils vont sortir tous les deux, mais pas "Meme", "Méme", "MeMé", et "Mêmé" (et tous les autres), non ? Me planté-je ?

Je regarde seulement le WHERE d'Eric...

Je ne vois pas comment écrire une clause WHERE simple/courte...
Sans générer TOUS les cas possibles... (ou récupérer TOUS les users pour les convertir côté PHP...)

Si je comprends bien, tu veux dire que c'est dans "l'intérieur" de MySQL, que tous les cas sont générés ? Et ça, ça peut affecter le temps de réponse ?

Whiler a écrit:

Je rephrase ce que j'ai compris... Eric pourra confirmer ou infirmer...

La question est comment tester si un nom d'utilisateur est déjà pris ou pas ?

Actuellement, on récupère tous les utilisateurs enregistrés, on les passe un par un à la moulinette LCAS pour obtenir la forme convertie en fonction de l'option LCAS choisie (Colonne comparaison dans le tableau du plugin)...
Une fois qu'ils sont tous passés, on sait que le nom est libre...

Comment simplifier pour ne pas charger tous les utilisateurs ?

Oui, c'est çà. Pour l'instant, çà se passe bien avec le code actuel car on teste généralement sur des galeries quasi-vides d'utilisateurs.
L'exemple de requête que j'ai proposé, je l'ai sorti comme çà sans même réfléchir si c'était correct. C'est vrai que le LIKE n'est probablement pas le plus approprié. Mais l'idée reste de "requêter" d'un coup les usernames en bdd qui matchent le username saisi (soit par un nouvel inscrit, soit par l'admin quand il traite les conflits) sans avoir à charger tous les username dans un tableau à chaque fois.

Dans l'absolu, on n'a besoin que d'une seule correspondance pour arrêter le processus d'inscription ou de renommage. En effet, s'il n'existe qu'un seul username en bdd, il devient inutilisable.

Whiler a écrit:

Eric a écrit:

En effet, s'il n'existe qu'un seul username en bdd, il devient inutilisable.

J'comprends pas ce que tu veux dire ?

Rien, laisses tomber :o)
Il commençait à se faire tard quand j'ai écrit çà et la journée avait été plus fatigante, et bla-bla-bla... Bref, je me suis embrouillé. ;-)

LucMorizur a écrit:

Pour répondre au questionnement en cours, je dirais : avons-nous le choix ? Car en fin de compte, on est bien obligé de vérifier, à certains moments, qu'un username proposé n'existe pas, et donc, potentiellement, de le comparer avec tous les username existants, en convertissant tout à la moulinette LCAS.

Oui.. mais ;o)
Il y a plusieurs solutions possibles : Soit, c'est PHP, soit c'est la DB, soit un mix des deux qui peut faire le taf...

Là, on utilise que PHP... qui prend tout et recherche partout...

Une autre solution serait de préparer une requête plus sophistiquée et de demander à la DB s'il y a des résultats...
Dans le genre... ça pourrait ressembler à ça, quand c'est insensible à la casse et aux accents...

Généré en PHP :
Utilisateur choisie : Béatrice (par exemple)
select username from user where LOWER(username) in ('beatrice', 'béatrice', 'bèatrice', 'bêatrice', 'bëatrice');

Si c'est sensible à la casse :
BÉA
select username from user where username in ('BEA', 'BÉA', 'BÊA', ...);

LucMorizur a écrit:

On peut imaginer une table "cache", qui stocke tous les username transformés par LCAS, mais dans le cas où le webmestre modifie son option LCAS, ou au moment de l'installation, ça risque de faire mal.

Oui, je suis d'accord, le cache me fait encore plus peur...

Whiler a écrit:

L'idée serait de
- générer la forme basique
puis de
- prendre tes tableaux de conversion à l'envers pour générer tous les cas possibles afin de les mettre dans une clause where user IN

C'est ce que je pensais aussi : Comparer les username sous une forme neutre. Par exemple : Mémé deviendrait meme pour toutes les comparaisons.

Whiler a écrit:

Je ne sais pas si ça vaut le coup ou pas... ?

L'idéal serait de mesurer les temps de traitement avec le code actuel sur une table de plusieurs centaines de users (+ de 100 au minimum) et d'effectuer la même mesure avec d'autres méthodes (table de cache, requêtes full MySql,...).

Perso, une de mes galeries aligne au max 73 users. C'est trop peu...