probleme de test d'existence d'un email en DB

[christouphe]

il faudrait faire le test...2 sec

C'est le premier rencontré:

DROP TABLE IF EXISTS `matable`;
CREATE TABLE IF NOT EXISTS `matable` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`pseudo` varchar(20) NOT NULL,
`email` varchar(20) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `pseudo` (`pseudo`),
UNIQUE KEY `email` (`email`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=3 ;

--
-- Dumping data for table `matable`
--

INSERT INTO `matable` (`id`, `pseudo`, `email`) VALUES
(1, 'toto', 'toto@toto.to');


puis:

INSERT INTO `matable` (`pseudo`, `email`) VALUES
('toto', 'toto@toto.to');

résultat:
#1062 - Duplicate entry 'toto' for key 'pseudo'

[Ter Rowan]

le souci que je vois à ta solution Christouphe (outre la charge que pourrait représenter le développement de la classe, qui peut être évacuer si on réutilise) c'est que tu n'auras qu'une erreur à la fois :


je reprends ton cas

en base on a déjà

toto / toto@toto.to

maintenant je me mets dans la peau de l'utilisateur lambda, je remplis le formulaire avec

toto / toto@toto.to

le message me répond "toto existe déjà,change de pseudo"
ok, discipliné, je change

tutu / toto@toto.to

et là miracle.. ah non, un nouveau message me répond "toto@toto.to existe déjà, change d'adresse email"

==> en expérience utilisateur, tu perds tout l'intérêt d'avoir en un coup toutes les erreurs détectées

[christouphe]

Donc tu penses qu'il est mieux de récupérer et de tester via PHP. Mais ton exemple est tangible. Même si la probabilité est infiniment infime, comme elle existe, il faut en tenir compte.

Mais ça m'embête niveau charge du serveur SQL...Justement dans ce cas actuellement...LOL donc tu vois pourquoi je suis un peu "tatillon"

[gameprog2]

Hummm.....

Je vous fais juste remarquer ça :

Maintenant : Sujet résolu !

Et aussi mon code fonctionne bien, j'ai le détail erreur de chaque champ, donc pas besoin de se compliquer la tête

[christouphe]

bah on ne fait que discuter sur les solutions possible de ton problème...

[gameprog2]

Oui je sais, chaque fois que je poste comme un newbee c'est une discussion de pros qui s'engage pendant des posts

[Plume]

Disons que ce n'est pas parce qu'une solution existe qu'il faut s'arrêter là. Ce n'est pas toujours la meilleure façon de faire qui a été proposée, par exemple. Et puis, nous restons dans le cadre du sujet alors pourquoi s'en priver.

Il faut bien s'améliorer.

[Plume]

J'avais pas vu ta modification, christouphe. Donc voilà, finalement, le serveur de base de données permet de gérer l'intégrité des données mais ta solution se montre finalement moins autonome en cas d'erreur. Et effectivement, l'expérience utilisateur connaitrait une régression avec cette même solution.

Conclusion : Autant continuer à faire comme montré au début. Une solution aurait été que le moteur soit en mesure de renvoyer toutes les erreurs éventuelles.

[gameprog2]

Une solution aurait été que le moteur soit en mesure de renvoyer toutes les erreurs éventuelles.

C'est le cas actuellement avec le code donné par Sephi-Chan et un peu modifié pour s'adapter à ce que je veux.

[Plume]

Un script PHP n'est pas un moteur. En l'occurrence, je parlais du moteur de stockage de données, dans notre conversation MySQL.