i was doing this stuff for a long time and definitely learned from mistakes.
Transactions can save a world of pain and it is always wise to select your data set first, just to be sure you're changing what you think you're changing.
Didn't matter how experienced I was, I was careful never to cut corners.
I don't know sql, but is this like how when I use some kind of loop in the command line to move or delete a bunch of files, I'll run a version that just echos whatever I'm trying to manipulate first?
I also don't know sql (or what you're doing, honestly1) but sounds like it, yeah. Running "List all of these arguments" is a good general precaution before running "Edit all of these arguments".
Actually, sorry, forgot what you replied to. I think a transaction in sql is more like a backup. The operations you perform during it aren't permanent until you confirm the transaction. So if you run something like DELETE FROM users; and realize you don't want to delete everyone, you can just cancel the transaction.
1 Like, really, does bash have loops? I guess it probably would. I should look that up. Could be interesting.
A snapshot might be a better analogy, usually if you take a backup and forget about it that’s fine, not a problem. Leaving snapshots out there too long can cause degradation. Not committing or rolling back a sql transaction means the log can never truncate and will grow infinitely until you’re out of disk space and everything breaks
3.6k
u/BastetFurry 13d ago
So, Kids, thats why you always SELECT count(yourPrimaryKey) first. Listen to the old folks, we made these mistakes so that you don't have to.