Anyone want to venture a guess as far as what kind of bug would cause a price cap like this?
Peter: "Oh! Well, this is not a mundane detail, Michael!"
Michael: "Hey, quit getting pissed at me. Alright? This was all your idea, ---hole!"
Peter: "Alright, okay, alright, let's try not to get pissed off at each other. Alright? Let's just calm down, let's try to figure this thing out together."
Anyway, downvoters, the quotes were an actual answer. It was probably some very minor detail that escaped notice until downstream effects (low price cap) made it evident. Without more information it's a waste of time to try guessing what that minor detail may have been.
Same with rm -Rf /foo/bar. There's a moment when pressing enter will do the wrong thing. I usually use relative paths to avoid this, but I have had to repair the damage for someone who actually managed to rm -Rf / by accident due to this.
Also for Update/Delete query I run the equivalent select (rows or count(*) ) query first, just to make sure.
also make sure to write where predicate before completing the whole sql. (The sql does not go through by accidentally hitting enter, before the whole statement is written)
tl;dr - Run read operation before doing write/update/delete operations.
It's hard to imagine how that would end up repricing items though. Without a total blanking out moment in the programmer's head, anyway, which I'm sure we've all been guilty of.
def build_query()
"UPDATE prices SET price=4995 #{where_clause}"
end
def where_clause() # only set prices on products in our group of stuff to sell
return "oops, I'm accidentally an empty string"
end