J'ai les triggers suivants sur ma table users qui copient la valeur dans le champ email du champ name. Ce déclencheur fonctionne correctement dans env local, mais en production, il va dans une boucle infinie. Quelqu'un a-t-il une idée de ce comportement?mysql trigger en boucle infinie
Les envs locaux et de production exécutent mysql 5.5.
Vous avez cette réponse de notre DBA. Donc, ce n'était pas un bug de récurrence (bien que le message d'erreur était vraiment mauvais, et ressemblait à un). Au contraire, c'était un problème de complexité de la mémoire.
Fondamentalement, chaque instruction doit s'exécuter dans un espace mémoire limité (128 Ko dans ce cas). Bien que la plupart des instructions soient bien moins nombreuses que cet espace, il semble que ce déclencheur nécessite beaucoup plus de mémoire.
La raison pour laquelle cela a fonctionné dans les tests est que les tests tentés n'étaient pas assez importants. (Et le serveur de test avait probablement plus de mémoire allouée)
À titre d'exemple, cela a fonctionné dans les tests:
UPDATE users SET name="[email protected]" WHERE id=1234;
Mais ce qui fonctionne vraiment dans la production est:
update users set full_name='Jason H', attr1='abc1', attr2='abc', attr3='adad' .... where id=1917;
Fondamentalement, le système java/hibernate est UPDATEing chaque champ ... pour une raison quelconque. C'est assez idiot, et hiberner probablement devrait faire moins.
La complexité considérablement plus grande de la requête réelle l'a poussée au-dessus des limites de mémoire en production.
Comment est-ce possible? le seul moyen est que vous ayez un enregistrement infini que je ne pense pas avoir, ou que le trigger s'appelle lui-même (fonction récursive) et que le nombre d'appels récursifs soit dans max_sp_recursion_depth ce n'est pas infini. – jcho360