<story><title>MySQL Bug #11472: Triggers not executed following foreign key updates/deletes</title><url>https://bugs.mysql.com/bug.php?id=11472</url></story><parent_chain></parent_chain><comment><author>pilif</author><text>if you rely on triggers for data integrity, then I guess this is one more case where MySQL is letting you down and allowing your data to get corrupted unless you&amp;#x27;re really careful.&lt;p&gt;While it&amp;#x27;s not always good design to use triggers for this, sometimes, it&amp;#x27;s a valid reason to use them for integrity checking or enforcing. Having `on delete` triggers not run for some delete&amp;#x27;s is violating the principle of least surprise.&lt;p&gt;When feature break this way, people start to distrust them and best practices get adopted that discourage using them, killing the features all together.&lt;p&gt;Using a database that does not have this misfeature, both triggers and foreign keys are perfectly safe to use, but because the one database that is the most widely used has issues like the one described here, you often hear the recommendation to not use triggers or even foreign keys.&lt;p&gt;Yes, you can potentially move the logic normally contained in either of them into the application, but as you deal with more concurrency and as you start accumulating bugs, sooner or later your data will be messy and you will need to add cleanup-scripts, or, heaven forbid, work around messy data in your application logic (don&amp;#x27;t. do. that. it&amp;#x27;s the path to the dark side of unmaintainability).&lt;p&gt;Or, of course, use a database system whose features work correctly and the principle of least surprise is in effect.&lt;p&gt;PostgreSQL is one of these, by the way.</text></comment>
<story><title>MySQL Bug #11472: Triggers not executed following foreign key updates/deletes</title><url>https://bugs.mysql.com/bug.php?id=11472</url></story><parent_chain></parent_chain><comment><author>Twirrim</author><text>It would be really awesome if MySQL crew could spend a few months (half a year?) working on paper-cuts:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;bugs.mysql.com&amp;#x2F;search.php?search_for=&amp;amp;status=Active&amp;amp;severity=&amp;amp;limit=10&amp;amp;order_by=&amp;amp;cmd=display&amp;amp;direction=ASC&amp;amp;os=0&amp;amp;phpver=&amp;amp;bug_age=0&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;bugs.mysql.com&amp;#x2F;search.php?search_for=&amp;amp;status=Active&amp;amp;...&lt;/a&gt;&lt;p&gt;That&amp;#x27;s all the active bugs against MySQL.  Note that this 10 year old bug isn&amp;#x27;t the oldest.&lt;p&gt;This is the oldest, from March 2003: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;bugs.mysql.com&amp;#x2F;bug.php?id=199&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;bugs.mysql.com&amp;#x2F;bug.php?id=199&lt;/a&gt;
Note someone submitted a fix for that over a year ago (and verified under the OCA in November) but it still hasn&amp;#x27;t shipped.  This is a bug that should never have taken 11 years to fix.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;bugs.mysql.com&amp;#x2F;bug.php?id=3052&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;bugs.mysql.com&amp;#x2F;bug.php?id=3052&lt;/a&gt;  This one is great.  ROLLBACK in a stored procedure doesn&amp;#x27;t close the cursor.&lt;p&gt;MySQL, for all its strengths, often feels like there is a bunch of typical geeks running the show.  Lots of focus on the &amp;#x27;sexy&amp;#x27; new features, not so much focus on keeping the lights on.</text></comment>