Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Soft deletion probably isn't worth it

brandur.org

Post reply on HN
Print view View original

231–240 of 514 posts

Re: Soft deletion probably isn't worth it

#231

Post by joshmanders »

rjzzleep wrote: post #170
JohnBooty wrote: post #151

I've been a software dev since the 90s and at this point, I've learned to basically do things like audit trails and soft deletion by default, unless there's some reason not to. Somebody always wants to undelete something, or examine it to see why it was deleted, or see who changed something, or blah blah blah. It helps the business, it helps you as developer by giving you debug information as well as helping you to c…

In rails you get these things for free. What I don't get is why everyone rolls their own framework with node.js. It's basically 90s PHP all over again. EDIT: Soft delete is a trivial piece of code when the framework has a well defined transaction system for its ORM. It's not really related to Rails per se. Your statement is extremely disingenuous, while trying to look smart. Audit trails _can_ be(but don't have to be…

I don't know why you're ragging on Node.js users or even PHP for that matter as both ecosystems have this stuff covered too.

Also you're comparing language/runtime with an actual framework and then dogging those users...

If you want to compare Rails with Node/PHP then I'd suggest comparing with things like Laravel (PHP), Adonis (Node) and you'll find everything you can do in Rails is done in Node/PHP too.

Re: Soft deletion probably isn't worth it

#232

Post by AdrianB1 »

Soft deletes are really worth in the right scenario. There are cases when they can be avoided, cases when they are not worth and cases when they are worth, for the problems presented in the article there are solutions or workarounds.

Re: Soft deletion probably isn't worth it

#233

Post by icedchai »

smackeyacky wrote: post #226
pradn wrote: post #187

Earlier quoted context omitted.

Soft deletion is just one way to achieve undeletion. The author's proposed solution of moving the resource to another table works just as well. You can move it back to the non-deleted table to perform the undeletion. You can keep around these deleted objects as long as you want; they work as a subset of a proper audit trail. The cost of course is you have more tables, but that is less of a cost than having to add "de…

What seems to be missing here is the DB tech he is using. On a proper database you can do your "undeleted" with triggers and it's relatively trivial. Nonsense like a "deleted" column on your main data table just seems silly.

I worked at a place that kept all the deleted stuff in their main tables. It turned out over 90% of the rows were deleted. I'm not sure how often something was undeleted, but it was not very frequent. Some of these soft deleted rows were 5+ years old. Archive that crap.

Re: Soft deletion probably isn't worth it

#234

Post by tsuujin »

augustl wrote: post #164
JohnBooty wrote: post #151

I've been a software dev since the 90s and at this point, I've learned to basically do things like audit trails and soft deletion by default, unless there's some reason not to. Somebody always wants to undelete something, or examine it to see why it was deleted, or see who changed something, or blah blah blah. It helps the business, it helps you as developer by giving you debug information as well as helping you to c…

This is why I don't understand why Datomic isn't more popular. Pretty much every system I've worked on never needed to scale past 100s of writes per second due to hard limits on the system (internal backoffice stuff, fundamenally scoped/shardable to defined regions, etc etc). And since Datomic is built with that in mind, you get the trade-off of full history, first class transactions and being able to query for thing…

It’s hard to get adoption for expensive toys.

I think Datomic is neat, and I’d like to use it, but it is prohibitively expensive for a personal or hobby project. Personal projects are where I get excited about tech, and when I’m excited I’m more likely to adopt it in my day job.

They’re really shooting themselves in the foot by not having a one-click install free tier or a self hosted option.

Re: Soft deletion probably isn't worth it

#235

Post by muhaaa »

Always use a temporal database (datomic, postgres with temporal_tables extension). You get out of the box the full history of your data. That is really helpful for business intelligence and analytics, auditing / audit log (security, accountability), live sync & real-time features and as a bonus easy recovery after application fails.

If disk gets to full, project the latest time slice into a new database and move the old database onto a cold storage.

Re: Soft deletion probably isn't worth it

#236

Post by wst_ »

wnevets wrote: post #182
JohnBooty wrote: post #151

I've been a software dev since the 90s and at this point, I've learned to basically do things like audit trails and soft deletion by default, unless there's some reason not to. Somebody always wants to undelete something, or examine it to see why it was deleted, or see who changed something, or blah blah blah. It helps the business, it helps you as developer by giving you debug information as well as helping you to c…

This is something that I was forced to learn the hard way more than once. Literally today I needed to undelete a record because a customer was confused by what the "delete" button did and wanted their record back.

Isn't it the problem of UI, though. If the user would be informed about the consequences (possibly with bold red font and with a confirmation checkbox) would they still click that button?

Re: Soft deletion probably isn't worth it

#238

Post by jasonhansel »

It's pretty easy to solve the foreign key issue (where you need to write elaborate DELETE queries to avoid breaking foreign keys) in Postgres using deferrable constraints. Just start a transaction, run "SET CONSTRAINTS ALL DEFERRED," delete rows from various tables in any order, then commit the transaction. The DELETE statements will effectively ignore the foreign key constraints, but any remaining "broken" foreign keys will be caught when the transaction commits.

Re: Soft deletion probably isn't worth it

#239

Post by robertlagrant »

smackeyacky wrote: post #226
pradn wrote: post #187

Earlier quoted context omitted.

Soft deletion is just one way to achieve undeletion. The author's proposed solution of moving the resource to another table works just as well. You can move it back to the non-deleted table to perform the undeletion. You can keep around these deleted objects as long as you want; they work as a subset of a proper audit trail. The cost of course is you have more tables, but that is less of a cost than having to add "de…

What seems to be missing here is the DB tech he is using. On a proper database you can do your "undeleted" with triggers and it's relatively trivial. Nonsense like a "deleted" column on your main data table just seems silly.

Triggers don't solve what the author's getting at, i.e. who knows what else outside this database changes upon deletion that would need to be reversed? It's all in the article.

Re: Soft deletion probably isn't worth it

#240

Post by robertlagrant »

efsavage wrote: post #193
JohnBooty wrote: post #151

I've been a software dev since the 90s and at this point, I've learned to basically do things like audit trails and soft deletion by default, unless there's some reason not to. Somebody always wants to undelete something, or examine it to see why it was deleted, or see who changed something, or blah blah blah. It helps the business, it helps you as developer by giving you debug information as well as helping you to c…

Also if people know that deletion is reversible, they're more likely to actually do it, which can keep things generally tidier. I don't actually like using a "deleted" column, my standard table has a status column, and deleted is one of those states, along with active/pending/suspended/etc, as the needs dictate. This way I get soft deletes for basically free both in the schema, but also in the queries (which would ge…

That still has the same issues. You have to remember to set every linked table's records to the same state, or remember to query every linked table through the table that has the lifecycle column on it.
Post reply on HN