4 ms·

Great postmortem and good lessons to learn here: * Don't manually modify database without a well-tested procedure and another pair of eyes * Don't leave persi

• scotty79 14y ago
  * while you are displaying a tree keep track of the items you already displayed so you can detect a cycle
  • sukuriant 14y ago
    I think the assumption there was that it was safe, since the code disallowed this from happening, naturally.
    • scotty79 14y ago
      Assumption is the mother of all screw ups. Even if you think that the code that creates and modifies your data will not put it in some undesired state, the code that uses this data should assume that the data may be in all undesired states you can dream up and should do its best not to do something seriously bad when that happens (like landing in endless loop/recursion or executing possibly user provided strings).
• JonM 14y ago
  * Don't push new code to production while operational problem is ongoing (unless it addresses the operational problem) ^^ absolutely!
• zzzeek 14y ago
  use CHECK constraints to prevent invalid data patterns when possible.
  • erichocean 14y ago
    Sadly, even that isn't enough. In our production database, I used CHECK constraints religiously. Worked great. Then one day, I was no longer able to commit ANY transactions to a particular table, even completely innocuous ones. The problem? The database itself had violated its own CHECK constraint on a previous commit, but was enforcing it on all subsequent commits, causing them to fail. Brilliant. Moral: not even CHECK constraints will save you. ---- P.s. This was a proprietary database, and when I reported the problem to the vendor (eventually, I figured out how to reproduce it), the vendor actually refunded our (expensive) support contract rather than fix the bug -- they couldn't figure out how to fix it despite having a small bug report that reproduced the problem. In the end, I actually had to remove the CHECK constraint altogether. :(
    • zzzeek 14y ago
      > The problem? The database itself had violated its own CHECK constraint on a previous commit, but was enforcing it on all subsequent commits, causing them to fail. Brilliant. I've never heard of that, and unless you're using a really buggy, broken database, it should not be possible. > P.s. This was a proprietary database, and when I reported the problem to the vendor well there you go. I think in practice, a simple CHECK constraint like the one we'd do here (literally, comment_id > parent_comment_id) is pretty easy to put one's faith into.
  • papsosouid 14y ago
    That's hard to do when you are afraid of databases and just store everything in files.