Programming

17406 readers

198 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 1 year ago

MODERATORS

[email protected]

365

I accidentally removed the WHERE clause from my SQL query in a personal tool. Every row is now the same. I overwrote 206,000+ rows. I have no backup, I am stupid. (lemmy.world)

submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]

115 comments fedilink hide all child comments

"UPDATE table_name SET w = $1, x = $2, z = $4 WHERE y = $3 RETURNING *",

does not do the same as

"UPDATE table_name SET w = $1, x = $2, y = $3, z = $4 RETURNING *",

It's 2 am and my mind blanked out the WHERE, and just wanted the numbers neatly in order of 1234.

idiot.

FML.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 3 points 1 year ago

Can prevent a restore, whereas doing the update with auto commit guarantees a restore on (mostly) every error you make

Exactly. Restores often result in system downtime and may take hours and involve lots of people. The backup might not have the latest data either, and restoring to a single table you screwed up may not be feasible or come with risk of inconsistent data being loaded. Even if you just created the backup before your statement, what about the transaction coming in while you're working and after you realize your error? Can you restore without impacting those?

You want to avoid all of that if possible. If you're mucking with data that you'll have to restore if you mess up, production or not, you should be working with an open transaction. As you said... if you see an unexpected number of rows updated, easy to rollback. And you can run queries after you've modified the data to confirm your table contains data as you expect now. Something surprising... rollback and re-think what you're doing. Better to never touch a backup and not shoot yourself in the foot and your data in the face all due to a stupid, easily preventable mistake.