Who are all you crack-junkies, running SQL queries against live...? I've seen enough literature saying we don't do this anymore... ooooooooohhhhhh. right... yes, the people writing about that aren't the ones actually shipping and making the clock tick ;-)
An UPDATE without a WHERE, or something close to it
41–50 of 112 posts
Re: An UPDATE without a WHERE, or something close to it
#42With databases, start a transaction first, then update, and look at the number of rows affected. If it's an oh shit moment, rollback, if not commit.
[deleted]
Re: An UPDATE without a WHERE, or something close to it
#43Surely this will become a non-problem as we migrate to NOSQL... no...? oh? we're migrating back? great.
Re: An UPDATE without a WHERE, or something close to it
#44Surely this will become a non-problem as we migrate to NOSQL... no...? oh? we're migrating back? great.
This is not about SQL; it's about user interfaces. The author is only using SQL as an explanatory tool.
Re: An UPDATE without a WHERE, or something close to it
#45Re: An UPDATE without a WHERE, or something close to it
#46I have once typed "ROLLBACK" in order to get my heart started again -- I had updated the users table.
Re: An UPDATE without a WHERE, or something close to it
#47A particularly nasty aspect of SQL UPDATE syntax is the predicate order, i.e. SET is before WHERE. So when you type it in order, there's a dangerous phase you have to go through if you hit enter by accident. Having run an `mkfs.ext3 /dev/sda` (note the missing partition number) by accident, I've learned to start potentially destructive commands by typing first whatever makes that command a comment (# in shell, -- in…
> A particularly nasty aspect of SQL UPDATE syntax is the predicate order, i.e. SET is before WHERE. So when you type it in order, there's a dangerous phase you have to go through if you hit enter by accident.
I religiously write it out of order for this reason. The IDE complains for a bit, but it's better to deal with some squiggles for a few seconds until you've filled in the column assignments part.
Re: An UPDATE without a WHERE, or something close to it
#48A particularly nasty aspect of SQL UPDATE syntax is the predicate order, i.e. SET is before WHERE. So when you type it in order, there's a dangerous phase you have to go through if you hit enter by accident. Having run an `mkfs.ext3 /dev/sda` (note the missing partition number) by accident, I've learned to start potentially destructive commands by typing first whatever makes that command a comment (# in shell, -- in…
Predicate order in SQL is pretty dodgy all around and makes it hard to build intuition around SQL queries. In select, the actual SELECT clause (field selection) can usually be conceptualized as “happening” after all other clauses, but of course it comes first in the query.
This problem is fixed in query languages like EdgeQL.[0]
Re: An UPDATE without a WHERE, or something close to it
#49A particularly nasty aspect of SQL UPDATE syntax is the predicate order, i.e. SET is before WHERE. So when you type it in order, there's a dangerous phase you have to go through if you hit enter by accident. Having run an `mkfs.ext3 /dev/sda` (note the missing partition number) by accident, I've learned to start potentially destructive commands by typing first whatever makes that command a comment (# in shell, -- in…
One quick trick I use a lot in the shell is to run a known safe command with the argument first, and then run the dangerous command with the the !$ variable (the last argument of the previous command) so there's no possibility of a mistake in copying and pasting. Something like: `ls /tmp/junk; rm !$`.
I think !$ takes the last argument on the previous command in history, not previous one on the same line.. at least in bash. For example, if you do:
$ ls /
$ ls /tmp/junk; rm !$
EDIT: formatting
Re: An UPDATE without a WHERE, or something close to it
#50This has never happened to me.
A SQL statement without a WHERE looks too suspicious to me to make a mistake like that.