"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.

  • agilob
    link
    fedilink
    English
    43
    edit-2
    2 years ago

    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 UPDATE or DELETE without WHERE. Use it.

    • @[email protected]
      link
      fedilink
      72 years ago

      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?

  • @[email protected]
    link
    fedilink
    English
    42 years ago

    Pressing F to pay respects. R.I.P. in pieces

    Depending on how mission critical your data is…Set up delayed replicas and backups (and test that your backups can actually be restored from). Get a second pair of eyeballs on your query. Set up test environments and run it there before running it in production. The more automated testing you put into your pipeline, the better. Every edit should be committed and tested. (Kubernetes and GitLab Auto DevOps makes this kind of thing a cinch, every branch has a new test environment set up automatically)

    Don’t beat yourself up too much though. It happens even to seasoned pros.

  • @[email protected]
    link
    fedilink
    162 years ago

    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

  • AlphaOmega
    link
    fedilink
    106
    edit-2
    2 years ago

    This is a hard lesson to learn. From now on, my guess is you will have dozens of backups.

    • @[email protected]
      link
      fedilink
      622 years ago

      And a development environment. And not touch production without running the exact code at least once and being well slept.

        • @[email protected]
          link
          fedilink
          1
          edit-2
          2 years ago

          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

          • @[email protected]
            link
            fedilink
            42 years ago

            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.

    • @[email protected]
      link
      fedilink
      152 years ago

      I’ve read something like “there are two kinds of people: those who backup and those who are about to”

    • @[email protected]
      link
      fedilink
      272 years ago

      And always use a transaction so you’re required to commit to make it permanent. See an unexpected result? Rollback.

      • @[email protected]
        link
        fedilink
        112 years ago

        Transactions aren’t backups. You can just as easily commit before fully realizing it. Backups, backups, backups.

        • @[email protected]
          link
          fedilink
          202 years ago

          Yes, but

          1. Begin transaction
          2. Update table set x=‘oopsie’
          3. Sees 42096 rows affected
          4. Rollback

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

          • @[email protected]
            link
            fedilink
            32 years 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.

    • @[email protected]
      link
      fedilink
      222 years ago

      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.

  • @[email protected]
    link
    fedilink
    62 years ago

    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, z
    
    • @[email protected]
      link
      fedilink
      92 years ago

      I 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 = true
      

      where 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.name
      

      Now 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.

  • @[email protected]
    link
    fedilink
    English
    432 years ago

    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.

    • @[email protected]OP
      link
      fedilink
      English
      12 years ago

      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?

      • @[email protected]
        link
        fedilink
        22 years ago

        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.

        https://oracle.github.io/node-oracledb/

        • @[email protected]OP
          link
          fedilink
          English
          12 years ago

          Awesome, thanks for the info. Definitely super useful for debug mode whilst I’m fixing and tampering!

      • @[email protected]
        link
        fedilink
        English
        22 years ago

        No idea. My tools connect directly to the DB server, rather than going though any web server shenanigans.

  • Tarte
    link
    fedilink
    2
    edit-2
    2 years ago

    I‘m using DataGrip (IntelliJ) for any manual SQL tomfoolery. I have been where you are. Luckily for me, the tool asks for additional confirmation when doing any update/delete without where clause.

    Also, backups are a must, for all the right reasons and for any project.

  • @[email protected]
    link
    fedilink
    102 years ago

    I have done this too. Shit happens.

    One of my co-workers used to write UPDATE statements backwards limit then where etc, to prevent this stuff, feels like a bit of a faff to me.

    • @[email protected]
      link
      fedilink
      262 years ago

      I always write it as a select, before turning it into a delete or update. I have burned myself too often already.

      • @[email protected]OP
        link
        fedilink
        English
        22 years ago

        Oh I did that like a year ago.

        And then last night had an error that led me back near this code and stupidly thought “hey it’d look neater if those numbers were in order”

      • DacoTaco
        link
        fedilink
        22 years ago

        ^ this is a very good tip that ive been using myself too

  • @[email protected]
    cake
    link
    fedilink
    292 years ago

    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.