Discussion :

[boo64]

Salut à tous!

Dimanche 3h du mat, et chui là à me prendre la tête sur les triggers, va vraiment falloir que j'me trouve une fille, enfin bref...

Donc voila mon problème :
- J'ai 2 tables utilisateurs (une pour mon forum, l'autre pour le reste du système) que je voudrais synchroniser pour que certaines infos (id, nom, mail, pass) soient toujours identiques dans les 2 tables.

Par là, j'entends que si une modif est faite sur la table utilisateurs A, elle est reportée sur la table utilisateurs B, et vice-versa.

Pour ça, j'ai créé deux triggers "before update" sur les 2 tables, mais je me prends une erreur 1442 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
1442 - Can't update table 'mybb_users' in stored function/trigger because it is already used by statement which invoked this stored function/trigger.

Je pense que c'est parce que ça fait un genre de boucle :
J'update la table A, le trigger de A update la table B dont le trigger update la table A.........

Pour résumer, donc, je veux que le trigger de B ne se déclenche pas si l'update de B vient du trigger de A .

Savez vous s'il y a une astuce ou à défaut, un moyen conceptuel de contourner le problème?

Merci!

[ericd69]

salut,

y a pas une phase de trop dans ta "boucle"?

si tu mets à jour (update, delete, insert, c'est des triggers différents pour chaque action) A et que les triggers mettent à jour B pourquoi tu refais des triggers pour mettre à jour A...

en gros, si A et B ont des trucs en commun, A est, par exemple, ta référence pour mettre à jour B ou inversement...

[Yanika_bzh]

Demandez-vous pourquoi vous avez besoin de dupliquer vos données utilisateurs!
Est-ce qu'une jointure entre les 2 tables ne suffiraient pas à vous retourner l'intégralité de vos données, à moindre frais ?
Revoyez peut-être votre modèle de données.

bon courage

[boo64]

Salut,
Ben non, c'est que la modif peut venir de A ou de B...

Table Forum => Si l'utilisateur met à jour son login, la modif doit être reportée dans la table "système".

Table système => Si quelqu'un met à jour le login, la modif doit être reportée dans la table forum...

Mais ça me fait penser : Si on fait un update sur des valeurs et qu'aucune n'est différente ca déclenche quand même le trigger? Parce qu'en console ca dirait "0 rows updated" ...

Bon ce que je vais faire, c'est comparer les valeurs avant d'effectuer l'update. Comme ça si les valeurs sont identiques, les triggers ne font rien et plus de problème...

Un peu bourrin, je laisse le thread ouvert voir si quelqu'un n'a pas une solution au final, plus intelligente pour synchroniser ces 2 tables...

[Yanika_bzh]

Cela veut dire qu'un utilisateur peut avoir 2 logins differents ? (1 pour le forum et 1 pour le system)

[ericd69]

un trigger se déclenche sur un événement donc oui...

perso je suis comme yanika... je me demande pourquoi dupliquer ces données avec toutes les lourdeurs et tous les risques de loupé que ça peut engendrer...

ça ne serait pas plus simple d'unifier tout ça en n'utilisant que l'identification du forum pour le forum et le site?

[boo64]

Ben sans synchro oui , un utilisateur pourrait avoir 2 logins, et c'est bien pour ça qu'il me faut des triggers pour reporter les modifs...

Une table serait évidement plus simple mais ça n'est pas possible :
J'utilise les modules mysql d'authentification pour plusieurs services : sites web, proftpd etc. (concrètement pour apache, il s'agit de paramétrer l’authentification dans la définition du serveur virtuel)

L'idée c'est donc bien d'avoir une table utilisateurs pour tout un panel d'applis.

Seulement, les modules auth-mysql sont limités en fonctionnalités, et si on peut préciser le type de cryptage du password parmi 3 ou 4 possibilités, le md5(md5($passaword).$clé) utilisé par myBB (mon forum) pour stocker les mdp n'est pas gérable hors d'un environnement web...

Et il y a d'autres problèmes du même genre... Donc ne voulant pas aller modifier le php de myBB, j'ai dû me résoudre à faire 2 tables utilisateurs synchronisées, pensant que ça serait au final moins la galère à mettre en place que les modifs à faire sur MyBB et les autres services nécessaires au merge des 2 tables...

[Yanika_bzh]

Je ne connais pas la structure de votre applicatif, mais je ne comprends pas tres bien ou est l'impossibilité de n'utiliser qu'une 1 table utilisateurs dans votre cas (a moins que chaque appli possede sa base propre). De plus, une table par appli, ca veut dire modification de votre architecture a chaque nouvelle appli, de nouveaux triggers, de nouvelles insertions d'indexes, ...

[ericd69]

l'idée peut etre d'utiliser l'un ou l'autre des système (peu importe)... je te proposais de généraliser l'identification en te basant sur celle du forum pour justement pas la changer. tu as une table de liaison qui relie tes différents système d'identification et qui te permet d'appelé les fonction d'identification de chaque application en leur appliquant de manière transparente leur identifiant et mot de passe.

c'est, en résumé, le principe de l'openID..

sinon ne passe pas par des triggers mais par des procédures stockées... car je sais pas si tu risques pas de faire des déclenchement de triggers circulaires entre le 2 tables et donc ça peut nuire aux performances. En plus tua s plein de limitations sur les triggers mysql, presque pas sur les procédures.

enfin à toi de voir... y a pas une seule façon de faire les choses