"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.
this folks, is why you don’t raw dog sql like some caveman
Me only know caveman. Not have big brain only smooth brain
Raw dog is the fastest way to finish a task.
- productivity
- risk
It’s a trade-off
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
who thought it was a good idea to make the where condition in SQL syntax only correct after the set?? disaster waiting to happen
All (doesn’t seem like MsSQL supports it, I thought that’s a pretty basic feature) databases have special configuration that warn or throw error when you try to
UPDATEorDELETEwithoutWHERE. Use it.I tried to find this setting for postgres and Ms SQLserver, the two databases I interact with. I wasn’t able to find any settings to that effect, do you happen to know them?
It’s supported in MySQL and MariaDB out of box:
https://dev.mysql.com/doc/refman/8.0/en/mysql-command-options.html#option_mysql_safe-updates
In Postgres there is an extension for it:
https://supabase.com/docs/guides/database/extensions/pg-safeupdate
for postgres and Ms SQLserver
It’s not really a SQL Language feature, more an IDE feature. So to tell you where the settings are, we’d have to know which IDE you’re using.
For example, in DataGrip (which I think you can use both for postgres and MSSQL), there’s “Show warning before running potentially unsafe queries”
If you forgot to put the WHERE clause in DELETE and UPDATE statements, DataGrip displays a notification to remind you about that. If you omitted the WHERE clause intentionally, you can execute current statements as you planned.
I didn’t mean this as IDE thing, there is an extension to postgres and server configuration for mysql/mardiadb. Posted the links above
–i-am-a-dummy 😂
I didn’t mean this as IDE thing
Well, the link you’ve posted is specifically for MySQL CLI Client - Maybe I should have I said “Client” instead of “IDE” - but if he uses a different IDE/Client besides MySQL-CLI it’s probably a different setting
That would be SQL management studio and psql on the command line.
The best I could find was some plugins for SQL management studio (ssmsboost) and disable automatic commits for psql.
deleted by creator
I still remember that time (hours ago) when “fake your own death” was the top voted recommendation for recovering from a SQL mistake.
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 🙃
You all run queries against production from your local? Insanity.
If coffee simply does not get you out of bed in the mornings any more, you need to find your fix elsewhere 💁
you could use dbeaver that warns you for update and delete queries without a where clause, independently of the db system. I hope the functionality it’s still there since, for totally unrelated motivations, I always use a where clause, even when buying groceries.
This is a hard lesson to learn. From now on, my guess is you will have dozens of backups.
I’ve read something like “there are two kinds of people: those who backup and those who are about to”
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.
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
This is the way
Pro tip: transactions are your friend
Completely agree, transactions are amazing for this kind of thing. In a previous team we also had a policy of always pairing if you need to do any db surgery in prod so you have a second pair of eyes + rubber duck to explain what you’re doing.
Always SELECT first. No exceptions.
mind explaining?
I did when I made the query a year ago. Dumdum sleep deprived brain thought it would look more organised this way
This doesn’t help you but may help others. I always run my updates and deletes as selects first, validate the results are what I want including their number and then change the select to delete, update, whatever
I learned this one very early on in my career as a physical security engineer working with access control databases. You only do it to one customer ever. 🤷♂️
In MSSQL, you can do a BEGIN TRAN before your UPDATE statement.
Then if the number of affected rows is not about what you’d expect, doing a ROLLBACK would undo the changes.
If the number of affected rows did look about right, doing a COMMIT would make the changes permanent.
Yup, exact tip I was gonna write!
I have them commented out and highlight the COMMIT when I’m ready.
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.I once dropped a table in a production database.
I never should have had write permissions on that database. You can bet they changed that when clinicians had to redo four days of work because the hosting company or whatever only had weekly backups, not daily.
So, I feel your pain.
deleted by creator
I watched someone make this mistake during a screen share, she hit execute and I screamed “wait! You forgot the where!” Fortunately, it was such a huge database that SQL spun for a moment I guess deciding how it was going to do it before actually doing it, she was able to cancel it and ran a couple checks to confirm it hadn’t actually changed anything yet. I don’t think anything computer related has ever gotten my adrenaline going like that before or since
