"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’re not the first. You won’t be the last. I’m just glad my DB of choice uses transactions by default, so I can see “rows updated: 3,258,123” and back the fuck out of it.
I genuinely believe that UPDATE and DELETE without a WHERE clause should be considered a syntax error. If you want to do all rows for some reason, it should have been something like UPDATE table SET field=value ALL.
Because I’m relatively new at this type of thing, how does that appear on the front end? I’m using a js/html front end and a jsnode backend. Would I just see a popup before I make any changes?
If you’re asking about the information about the number of rows, oracle db clients do that. For nodejs, oracle’s library will provide this number in the response to a dml statement execution. So you can retrieve it in your backend code. You have to write additional code to bring this message to the front-end.
Awesome, thanks for the info. Definitely super useful for debug mode whilst I’m fixing and tampering!
No idea. My tools connect directly to the DB server, rather than going though any web server shenanigans.
Postgres has a useful extension, pg_safeupdate
https://github.com/eradman/pg-safeupdate
It helps reduce these possibilities by requiring a where clause for updates or deletes.
I guess if you get into a habit of addingwhere 1=1to the end of your SQL, it kind of defeats the purpose.Transactions help more, IMO. The 1=1 becomes a real habit.
MySQL (and by extension, MariaDB) has an even better option:
mysql --i-am-a-dummy
Amazing! These are going in my.conf ASAP.
There is still the journal you could use to recover the old state of your database. I assume you commited after your update query, thus you would need to copy first the journal, remove the updates from it, and reconstruct the db from the altered journal.
This might be harder than what I’m saying and heavily depends on which db you used, but if it was a transactional one it has to have a journal (not sure about nosql ones).
It is after the event that I find that postgres’ WAL journalling is off by default 🙃
Unrelated, but use placeholders instead of interpolation right into the query.
See: Little Bobby Tables. https://xkcd.com/327/
That’s what they’re doing…
If true, great. I’ve not run across a language / RDBMs library that uses numbered place holders over the standard
?, but I’m sure someone’s done it.
this folks, is why you don’t raw dog sql like some caveman
Yep. If you’re in a situation where you have to write SQL on the fly in prod, you have already failed.
Tell that to my former employer…
Yeah, I swear it’s part of the culture at some places. At my first full-time job, my boss dropped the production database the week before I started. They lost at least a day of records because of it and he spent most of the first day telling me why writing sql in prod was bad.
it’s time to commit sqlpukku
Me doing it for multiple years in a Bank…Uhm…
(let’s just say I am not outting my money near them… and not just because of that but other things…)
Me only know caveman. Not have big brain only smooth brain
But the adrenaline man… some of us are jonkies of adrenaline but we are too afraid of anything more of physically dangerous…
You may be interested in suicide linux then. it’s a distro that wipes your entire hard drive if you mistype a command
Raw dog is the fastest way to finish a task.
- productivity
- risk
It’s a trade-off
There’s no way you’re endorsing the way OP handled their data right?
No, but people are sometimes forced to do these things because of pressure from management and/or lack of infrastructure to do it in any other way.
Definitely don’t endorse it but I have done it. Think of a “Everything is down” situation that can be fixed in 1 minute with SQL.
Got it. I’m with you.
who thought it was a good idea to make the where condition in SQL syntax only correct after the set?? disaster waiting to happen
The people designing SQL, not having learned from the mistakes of COBOL, thought that having the syntax as close to English as possible will make it more readable.
I did that once when I moved from one DB IDE to another and didn’t realise the new one only ran the highlighted part of the query.
there were thousands of medical students going through a long process to find placements with doctors and we had a database and custom state machine to move them through the stages of application and approval.
a bug meant a student had been moved to the wrong state. so I used a snippet of SQL to reset that one student, and as a nervous habit highlighted parts of the query as I reread them to be sure it was correct.
then hit run with the first half highlighted, without the where clause, so everyone in the entire database got moved to the wrong fucking state.
we had 24 hourly backups but I did it late in the evening, and because it was a couple of days before the hard deadline for the students to get their placements done hundreds of students had been updating information that day.
I spent until 4am the next day working out ways to imply what state everyone was in by which other fields had been updated to what, and incidentally found the original bug in the process 😒
anyway, I hope you feel better soon buddy. it sucks but it happens, and not just to you. good luck.
This is about the one thing where SQL is a badly designed language, and you should use a frontend that forces you to write your queries in the order (table, filter, columns) for consistency.
UPDATE table_name WHERE y = $3 SET w = $1, x = $2, z = $4 RETURNING * FROM table_name SELECT w, x, y, zI get mildly mad all the time when writing SQL because I feel like it’s upside down
Instead of
select u.id. u.email, p.name from user u join persona p on p.user_id = u.id where u.active = truewhere the columns are referenced before they’re defined (like what is u.id? Keep reading to find out!)
it should instead be
from user u join persona p on u.id = p.user_id where u.active = true select u.id, u.email, p.nameNow nothing is defined before it’s used, and you’re less likely to miss your where clause. I usually write the joins first anyway because I know what tables I care about, but don’t know which specific things I’ll want.
I can’t think of any other languages that use things before they’re defined except extremely dysfunctional JavaScript.
From the cabinet, get a cup.
You might enjoy https://github.com/max-sixty/prql
This is a hard lesson to learn. From now on, my guess is you will have dozens of backups.
And a development environment. And not touch production without running the exact code at least once and being well slept.
Fuck that, get shit housed and still do it right. That’s a pro.
That’s not pro, that’s just reckless gambling.
Totally right! You must set yourself up so a fool can run in prod and produce the expected result. Which is the purpose of a test env.
Replied hastily, but the way to run db statements in prod while dealing with sleep deprivation and drinking too much is to run it a bunch in several test env scenarios so you’re just copy pasting to prod and it CAN confidently be done. Also enable transactions and determine several, valid smoke tests.
Edit: a -> several
I’ve read something like “there are two kinds of people: those who backup and those who are about to”
This is the way
And always use a transaction so you’re required to commit to make it permanent. See an unexpected result? Rollback.
Transactions aren’t backups. You can just as easily commit before fully realizing it. Backups, backups, backups.
Backups are for emergencies.
Transactions are for oopsies.
Yes, but
- Begin transaction
- Update table set x=‘oopsie’
- Sees 42096 rows affected
- Rollback
Can prevent a restore, whereas doing the update with auto commit guarantees a restore on (mostly) every error you make
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.
Things like this make me glad I can only query my db.
I learned this lesson too
Oof. Been there, done that, 0 stars; would not recommend.
If it’s Microsoft SQL you should be able to replay the transaction log. But you should be doing something like daily full backups and hourly incremental or differential backups to avoid this situation in the first place.
Been there, done that, I hope you have a recent backup!
I learned the hard way about the beauty of backups and the 3, 2, 1 rule. And snapshots are the GOAT.
Even large and (supposedly) sophisticated teams can make this mistake, so dont feel bad. It’s all part of learning and growth. You have learned the lesson in a very real and visceral way - it will stick with you forever.
Example - a very large customer running our product across multiple servers, talking back to a large central (and shared) DB server. DB server shat itself. They called us up to see if we had any logs that could be used to reconstruct our part of their database server, because it turned out they had no backups. Had to say no.
