Live data from Hacker News

I Accidentally Deleted All Our Data

taylor.fausak.me

21–30 of 78 posts

Re: I Accidentally Deleted All Our Data

#21
post #3

I've done this a few times in my career. I'm smart enough now to always backup before I make any potential mistakes and test everything on a staging server. The worst was executing "DELETE FROM " instead of "DELETE FROM where userid='X' on a production server.

If I were to re-imagine SQL I'd invert the sequence of the clause and statement for this very reason (FROM TABLE WHERE USERID="X" DELETE). As it, when I'm writing sensitive SQL to fix an issue I end up writing the where clause first as a SELECT, then issue it.. check the results, history up, ctl-a and replace with a DELETE. Harrowing stuff.

I put in a deliberate syntax error first, and then edit in the actual delete or update query. This protects me from hitting enter too early.

Re: I Accidentally Deleted All Our Data

#22

"We had a backup from earlier in the week" week? That seems kind of off. I'd suggest setting up backups more often than that, especially for production data. Sorry to hear about that. I destroyed a drive once a long time ago (~1994) as well. Happens to the best of us.

Because of this, we're going to back up parts of our database more frequently. A lot of our data isn't mission critical, so it wouldn't make sense to do daily backups for it. Other things, like family accounts, obviously are. We're going to back those up daily from here on out.

Re: I Accidentally Deleted All Our Data

#24
post #23

I wonder if it's possible that it was a MongoDB glitch and not a user error. From what I've read, it's notorious for randomly losing records. Maybe the loop save triggered it?

I definitely don't attribute this to MongoDB (or MongoEngine or pymongo or Django). I haven't seen it lose any of our documents to date. Silently dropping documents when saving them without making any changes would be a huge problem. It's astronomically unlikely.

Re: I Accidentally Deleted All Our Data

#25

Who works with a prod database in an interactive interpreter? My eyes are literally wide in shock.

You never connected to your live database using `mysql` (pg, whatever) with a privileged user? Using the frameworks shell is almost the same, except that all client-side validations work.

Re: I Accidentally Deleted All Our Data

#27

Hey guys, I accidentally all of our data. Is this dangerous?

I originally titled this post "I Accidentally All Our Data", but my girlfriend convinced me to change it. I also considered "Delete ALL the Data", but I went for the meme-free title.

Re: I Accidentally Deleted All Our Data

#29
post #8
post #6

Although direct database update isn't recommended in SAP, still for some strange reasons it was needed in one of the projects to modify a wrong entry done by functional consultant. One of my fellow programmer was assigned this task and this is what she did - Update set = instead of Update set = where The code was executed on development server(thankfully) and it created a big mess. Full day work of 5 guys was lost. P…

Sounds like a poor manager to me.

Sounds like a poor manager to me.

Agreed, sounds like an absolutely abysmal manager. As long as the developer wasn't in the habit of making such mistakes, I would have put her in charge of any future similar changes.

Re: I Accidentally Deleted All Our Data

#30
post #3

I've done this a few times in my career. I'm smart enough now to always backup before I make any potential mistakes and test everything on a staging server. The worst was executing "DELETE FROM " instead of "DELETE FROM where userid='X' on a production server.

A buddy of mine showed me a cool trick to avoid this type of problem. What you do is first use SELECT to see the records in question: SELECT * from some_table where idx >= 5 Then, once you are staring at the records that came back (and are sure they are the ones you want to delete), change SELECT * to DELETE (and change nothing else) and rerun. DELETE from some_table where idx >= 5 Pretty hard to get it wrong with th…

Or even better, SELECT(*) FROM some_table - that way the developer won't be tempted to skip the step because of too many records scrolling through their screen... not that I learned that from personal experience or anything ;-)
Post reply on HN