6 ms·

"Even more unfortunately, I didn’t back up the database before I began this process." That's the takeaway here, no matter how much of a hassle it is backup the

"Even more unfortunately, I didn’t back up the database before I began this process." That's the takeaway here, no matter how much of a hassle it is backup the DB before you practice delete-fu - no matter how ninja you are you will make a mistake.

JonnieCache 15y ago
We had this debate a couple of weeks ago: always clone your DB to a staging or local server and practice on that, and never do your delete-fu in a REPL! But as we all hated that bloody website anyway I doubt anyone will shed a tear. Maybe it was a relational-algebra-based freudian slip...
billybob 15y ago
Definitely. And after you back up, do a SELECT, confirm you're seeing the correct records, and only then change the SELECT to a DELETE.
deleted 15y ago
[deleted]
wvenable 15y ago
If you have a good setup, you shouldn't need to backup the database before every destructive operation. If I went in and accidentally deleted every user record in my database right now -- the site would crash -- but I would be able to restore the site to the point judt before I screwed it up. This recovery would come from the last full backup and the transaction logs. If my server crashes, the hot replicated backup server will take over. If a hacker destroys both servers and all local backups then I have my last full offsite backup and my nightly off-site transaction log backups so, at most, I'd lose one day. And I'm not much of a sysadmin -- I've a sole developer and I usually sysadmin by Googling everything and using some common sense and yet I still managed to throw this setup together. You would think a site as big and important as jQuery would put have some common-sense backup procedures in place.
angrycoder 15y ago
There are two periods in your career when you are most likely to this: when you very little experience or a whole lot of experience. The former because you have no idea what you are doing, the latter because goddamnit I know what I'm doing.

JonnieCache 15y ago

We had this debate a couple of weeks ago: always clone your DB to a staging or local server and practice on that, and never do your delete-fu in a REPL! But as we all hated that bloody website anyway I doubt anyone will shed a tear. Maybe it was a relational-algebra-based freudian slip...

billybob 15y ago

Definitely. And after you back up, do a SELECT, confirm you're seeing the correct records, and only then change the SELECT to a DELETE.

deleted 15y ago

[deleted]

wvenable 15y ago

If you have a good setup, you shouldn't need to backup the database before every destructive operation. If I went in and accidentally deleted every user record in my database right now -- the site would crash -- but I would be able to restore the site to the point judt before I screwed it up. This recovery would come from the last full backup and the transaction logs. If my server crashes, the hot replicated backup server will take over. If a hacker destroys both servers and all local backups then I have my last full offsite backup and my nightly off-site transaction log backups so, at most, I'd lose one day. And I'm not much of a sysadmin -- I've a sole developer and I usually sysadmin by Googling everything and using some common sense and yet I still managed to throw this setup together. You would think a site as big and important as jQuery would put have some common-sense backup procedures in place.

angrycoder 15y ago

There are two periods in your career when you are most likely to this: when you very little experience or a whole lot of experience. The former because you have no idea what you are doing, the latter because goddamnit I know what I'm doing.