sql triggers gone bad: cand un select face scrieri
Motivul principal pentru care nu-mi plac triggerele SQL si le evit pe cat pot este ca contravin "principle of least surprise", adica in opinia mea ar trebui ca uitandu-te la o aplicatie sa-ti dai seama ce date ajung in baza de date si cum le gasesti daca te uiti dupa ele, eviti cod care nu e versioned, se simplifica backupul bazei de date, etc. Evident, cand ratiunile de performanta o cer, te poti apuca sa le implementezi, dar cu grija si prudenta. Am mai avut cu cativa colegi niste flame pe tema asta, si de obicei ajungem repede la concluzia ca "depinde". In orice caz cadem destul de repede de acord ca adaugarea unui trigger pe un select e ceva cu mare potential de bad voodoo, pentru ca faci scrieri cand te astepti sa faci doar citiri. O alta anecdota utila pentru flame de genul asta am citit ieri pe blogul lui Mihai Brehar: la un insert values aparent inofensiv s-a trezit cu o eroare de where clause care s-a dovedit a proveni dintr-un trigger insuficient testat (astfel incat sa trateze corect diversele erori). Mi se pare un "book example" de caz in care utilizarea de tranzactii ar mentine socotelile curate.
Insa cea mai tare faza de genul asta citita pana acum este bugul acesta. Pe scurt, in mysql engine-ul NBD are un trigger intern care facea cleanup la anumite tabele in momentul in care rulai "show tables" pe unul din membrii clusterului. Not very funny.