←back to thread

475 points danielstocks | 3 comments | | HN request time: 0s | source
1. OJFord ◴[] No.27309220[source]
I think this would make quite an interesting exercise for whatever it is one works on oneself; that is, what's the minimum, most innocuous patch that causes this behaviour?

I bet it's not as much as people railing against it would like to think.

I'm partly thinking of this because I fixed a (way less critical) bug today that boiled down to a (x - y) * z = 0 query that should've just been (x - y) = 0. But it was hidden by the whole expression being named, and that then seeming correct, it not being obvious that `z` could be 0 (or was involved at all) and as a result unwanted results would be included where x != y.

Probably the most obvious one is different IDs - have two fk columns that sound a bit similar and it's easy to come a cropper, getting 'random' records that correspond to a given ID but that's for the wrong table...

replies(1): >>27309268 #
2. kenniskrag ◴[] No.27309268[source]
> getting 'random' records that correspond to a given ID but that's for the wrong table...

That's why I use GUID instead of integers. If you get a result, it was the right column.

replies(1): >>27312659 #
3. OJFord ◴[] No.27312659[source]
Good point, we do for new things, but of course when I hit it it was with an old table and was a problem.. sod's law. (Though arguably it's just harder to notice the effects of it happening with a GUID and it could have too.)