4 ms·

When disk space is limited and you are working with large files, you need to clean up after yourself. And human make mistakes. I am not sure if this still does

• Joeri 10y ago
  Yup, I did something like that command once, to a project developed over 3 months by 5 people without a backup policy (university group project). Luckily, this was in the days when most of the work was done on non-networked computers, so we cobbled everything together from partial source trees on floppies, hunkered down for a week to hammer out code and got back to where we were before. It's amazing how fast you can write a piece of code when you've already written it once before. That was the day I started backing up everything.
• aidos 10y ago
  Day 1 in my first job in the UK I ran an "update crucial_table set crucial_col = null" without a where clause on production. Turned out there were no backups. Luckily the previous day's staging env had come down from live, so that saved most of the data. What most people don't realize is that very few places have a real (tested) backup system. _goes off to check backups_
  • rrauenza 10y ago
    I had a coworker who would always do manual dangerous SQL like these within a transaction ... and would always mentally compare the "rows affected" with what he thought it should be before committing. And then commit it. It's a good habit.
    • mulmen 10y ago
      I have never done what the GP describes but I consider myself very lucky as it's a very common mistake. I have heard enough horror stories to always keep that concern in the back of my mind. I do what your coworker did and it's a great feeling when you get the "451789356 rows updated" message inside a transaction where you are trying to change Stacy's last name after her wedding and all you have to do is run a ROLLBACK. Then it's time to go get a coffee and thank your deity of choice.
    • desas 10y ago
      Not doing this is like juggling with knives. I cringe every time I see a colleague doing it.
    • DrPhish 10y ago
      My workflow for modifying production data is: 1) Write a select statement capturing the rows you want to modify and verify them by eyeball 2) (Optional) Modify that statement to select the unchanged rows into a temp table to be deleted in a few days 3) Wrap the statement from step 1 in a transaction 4) Modify the statement into the update or delete 5) Check that rowcounts haven't changed from step 1 6) Copy-and-paste the final statement into your ticketing or dev tracking system 7) Run the final statement It may be overkill, but the amount of grief it can save is immeasurable
    • rzzzt 10y ago
      MySQL's console can also warn you if you issue a potentially destructive statement without a WHERE clause: http://dev.mysql.com/doc/refman/5.7/en/mysql-tips.html#safe-updates http://dev.mysql.com/doc/refman/5.7/en/mysql-tips.html#safe-...
      • dotancohen 10y ago
        The `--i-am-a-dummy` flag, which I wish were called `--i-am-prudent` because we all are dummies.
    • lobster_johnson 10y ago
      One of PostgreSQL's best features is transactional DDL: You can run "drop table" etc. in a transaction and roll back afterwards. This has saved me a few times. It also makes it trivial to write atomic migration scripts: Rename a column, drop a table, update all the rows, whatever you want -- it will either all be committed or not committed at all. Surprisingly few databases support this. (Oracle doesn't, last I checked.)
    • scriptman 10y ago
      I do a select first using the where clause I intend to use to get the row count. Then open a transaction around the update with that same where clause, check the total number of rows updated matches the earlier select, then commit. This approach definitely reduces your level of anxiety when working on a critical database.
    • foobarian 10y ago
      It works for more than databases. - With shells, I prefix risky commands on production machines with #, especially when cutting and pasting - Same for committing stuff into VCS, especially when I'm cherrypicking diffs to commit - Before running find with -delete, run with -print first. Many other utilities have dry-run modes
    • lysp 10y ago
      My practise is to do: UPDATE ImportantTable SET ImportantColumn = ImportantColumn WHERE Condition = True Check the rows affected, then change it to: UPDATE ImportantTable SET ImportantColumn = NewValue WHERE Condition = True
  • grrowl 10y ago
    Lots of people "do backups", not many have a "disaster recovery plan" and very few have ever practised their disaster recovery plan. Years ago we had an intern for a time, and he set up our backup scripts on production servers. He left after a time, we deleted his user, and went on our merry way. Months later, we discover the backups had been running under his user account, so they hadn't been running at all since he left. A moment of "too busy" led to a week of very, very busy.
  • pavel_lishin 10y ago
    I've done that where crucial_col happened to be the password hash column. We managed to restore all but about a dozen users from backup, and sent a sheepish email to the rest asking them to reset their passwords.
• FabHK 10y ago
  > The real solution is comprised of * making "--preserve-root" the default... :-)
• vacri 10y ago
  I am finding more and more that the 'f' is not required. Just 'rm -r' will get you there usually, and so I'm trying to get into the habit of only doing the minimum required. Unfortunately, git repos require the -f.
• arximboldi 10y ago
  Accidents like these have happened to me enough times that my .bashrc contains this in all my machines: alias rm='echo "This is not the command you are looking for."; false' I install trash-cli and use that instead. Of course this does not prevent other kinds of accidents, like calling dd to write on top of the /home partition... ok, I am a mess :)
• DonHopkins 10y ago
  Now days with the low price of disk space and high price of time, it's much cheaper to buy new disk drives than to pay people to delete files. And safer!