Ouch. Gotta wrap those deletes in a transaction and look before it rolls forward.
Lessons learned. Time to see if the backups actually have any data on them.
As a side note, DBeaver actually asks for confirmation if it thinks you are about to do something wonky. I think it’s quite telling just how common this mistake is. We’ve all been there
Good companies wouldn’t fire someone for this because:
There should be processes in place to prevent this, or recover from this, anyway. It’s a team/department failure and you would just be the straw that broke the camel’s back.
They now know you’ve experienced this and will hopefully know to never do it again. Bringing in someone else could just reintroduce the issue.
I did something like that once, I wasn’t very good at SQL but I needed some data, so I logged in into the production database and run my SELECT queries, I didn’t change anything so everything was good, or so I thought.
I created a cross product over tables with millions of entries and when it didn’t respond I thought it was odd but it was time to go home anyway. On the way home they called me and asked what I did. They had to restart the DB server because once the cache timed out one application after another started failing.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
You just triggered my PTSD
Embrace it as you are now officially a developer
At some point this is just a rite of passage
Mine was to format the wrong computer on the first day of my first IT internship. I spent the next six weeks there fixing that oopsie.
I don’t even work with databases but I still have a fear of possibly doing this someday.
If it happens, it’s a lack of control, and, at least mostly, not your fault
Ouch. Gotta wrap those deletes in a transaction and look before it rolls forward. Lessons learned. Time to see if the backups actually have any data on them.
Don’t call it “accidental database deletion”. Call it “unannounced live exercise of backup procedure”.
Either that or rapid exodus from the country
“I didn’t put a WHERE clause in that DELETE statement”
As a side note, DBeaver actually asks for confirmation if it thinks you are about to do something wonky. I think it’s quite telling just how common this mistake is. We’ve all been there
Update and delete should require a where clause. You can always use true or 1 = 1, the gain from omitting it is minimal.
The fact that no DBMS ever decided to implement this, not even as an option is quite distressing.
DB admins rawdogging the prod postgres on a Friday evening.
Sometimes I dream of getting fired for accidentally doing shit like this. Sweet relief…
Good companies wouldn’t fire someone for this because:
There should be processes in place to prevent this, or recover from this, anyway. It’s a team/department failure and you would just be the straw that broke the camel’s back.
They now know you’ve experienced this and will hopefully know to never do it again. Bringing in someone else could just reintroduce the issue.
I did something like that once, I wasn’t very good at SQL but I needed some data, so I logged in into the production database and run my SELECT queries, I didn’t change anything so everything was good, or so I thought.
I created a cross product over tables with millions of entries and when it didn’t respond I thought it was odd but it was time to go home anyway. On the way home they called me and asked what I did. They had to restart the DB server because once the cache timed out one application after another started failing.