News for hackers. Stuff that matters.
Re:How I destroyed the company's DB (a stupid SQL mistake) by awestroke on Monday January 01, 2024 @01:20PM (#38833947)
SQL really sucks. DELETE without WHERE should be a syntax error. Use `where id=id` if you really want everything gone.
Re:How I destroyed the company's DB (a stupid SQL mistake) by crazygringo on Monday January 01, 2024 @01:29PM (#38834056)
Because of this, it's also customary to use a LIMIT just in case.

For something like this, LIMIT 3 if you assume the query is correct (e.g. in production), or LIMIT 4 if you're running it manually -- so that if it reports 4 rows changed instead of 3, you know you messed up somewhere, but at least you only have up to 4 rows to fix by hand, rather than an entire table.

Re:How I destroyed the company's DB (a stupid SQL mistake) by AntonZ234 on Monday January 01, 2024 @01:35PM (#38834130)
I’m used to using limits purely in select queries, honestly I didnt event know its applicable for update queries.

Still, it would probably have been after the where, and ignored too.

not using transactions is probably my biggest mistake here.

Re:How I destroyed the company's DB (a stupid SQL mistake) by cortesoft on Monday January 01, 2024 @01:38PM (#38834167)
Would not have helped, since the limit would have applied to the second statement in this case.

The issue wasn’t the statement, it was the tool thinking blank line == end ststement.

Re:How I destroyed the company's DB (a stupid SQL mistake) by mlyle on Monday January 01, 2024 @01:35PM (#38834119)
Of course, the LIMIT is no good here because the correctly-written statement is truncated.
Re:How I destroyed the company's DB (a stupid SQL mistake) by syslog on Monday January 01, 2024 @01:30PM (#38834061)
A decent database has transactions, so you can rollback your fat-fingered queries.
Re:How I destroyed the company's DB (a stupid SQL mistake) by cafard on Wednesday January 03, 2024 @10:06AM (#38854898)
Postgres and SQL Server have always had transactions; but unless you frame your DML in BEGIN TRANSACTION/[COMMIT|ROLLBACK], each statement is committed as executed.

If you broke in on Oracle, where you must explicitly commit statements (unless your client sets up auto-commit), this can take some getting used to.

Re:How I destroyed the company's DB (a stupid SQL mistake) by crazygringo on Monday January 01, 2024 @01:33PM (#38834103)
Yeah, I'd definitely be in favor of a flag that didn't allow DELETE without WHERE. Too easy to accidentally hit enter before you finish writing the query, in certain circumstances.

Disable the flag if you want pure SQL. And just use "WHERE true" otherwise.

Re:How I destroyed the company's DB (a stupid SQL mistake) by Karellen on Monday January 01, 2024 @02:38PM (#38834672)
But... this query used

    UPDATE orders
    SET is_deleted = true
DELETE without WHERE wasn't part of the problem.
Re:How I destroyed the company's DB (a stupid SQL mistake) by awestroke on Monday January 01, 2024 @03:08PM (#38834904)
Good idea, let’s enforce WHERE on UPDATE as well
Re:How I destroyed the company's DB (a stupid SQL mistake) by paulryanrogers on Monday January 01, 2024 @01:28PM (#38834038)
Could probably be done with a DB statment-level trigger. It's sometimes useful to flush tables for testing or work tables. TRUNCATE is even a special case command for such purposes.
Re:How I destroyed the company's DB (a stupid SQL mistake) by maxbohun on Monday January 01, 2024 @01:44PM (#38834227)
It shouldn’t be error, but it has to warn you..are u sure to execute this query?…(by default)
Re:How I destroyed the company's DB (a stupid SQL mistake) by awestroke on Monday January 01, 2024 @02:06PM (#38834410)
Why not an error? How often do you truncate a table? Often enough that you can’t afford to type ` where true `?