Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • It seems like half the posts you make are how you had yet another near-miss with your data.

    I'm not sure "It sucks when you're afraid of your database.", I'd say your development environment is broken. If your database isn't guaranteeing the integrity of your data, what the hell is it doing?

    I'd be expecting you to have a best-of-breed text editor, version-control system, language :-) etc. and I'm puzzled why you put up with something that's clearly second-best for your usage.

    Disclosure - been using Postgre

    • I think you just answered your own question.

    • It's not my choice, believe me. Plus, some developers on our team don't care enough about the bugs. They're in a comfort zone.

      • This would be a perfect opportunity for some quiet smugness were I not tracking down a bug in some old PHP v4 (well, some if it's PHP v3) code :-/
  • To be fair, the fact that you're not using strict mode to avoid truncation isn't really the fault of MySQL.

    • We use 'traditional' mode and that should have blocked this, but for some reason, it was disabled at that particular time . This may have had something to do with the annoying fact that traditional mode is not the default (because, after all, why would you want maintaining data integrity to be the default behavior?)

      However, in MySQL, when you re-enable foreign key constraints, while it may be time-consuming, it should still validate that the constraints hold.