Soft deletion probably isn't worth it • Hacker News Board

Re: Soft deletion probably isn't worth it

#261

Post by doctor_eval » Tue, Jul 19, 2022, 10:53 PM UTC

madisp wrote: post #229

rodw wrote: post #205

Earlier quoted context omitted.

Seriously. That "Downsides: Code leakage" point is nonsensical. ``` CREATE OR REPLACE VIEW active_customer AS SELECT * FROM customer WHERE deleted_at IS NULL OR deleted_at There, I fixed it. Just use `active_customer` instead of `customer ... deleted_at IS NULL`. In fact, since the deleted_at column is a timestamp, the original "leakage" query: ``` SELECT * FROM customer WHERE id = @id AND deleted_at IS NULL; ``` is…

I'd argue that the simple `deleted_at IS NULL` check is not broken - unless your product / domain specifically allows and requires scheduled future deletions adding such logic can easily introduce bugs. For example, you could to get the comparison flipped by accident, and if it's only in one place out of many that bug could go unnoticed for a while.

You don't put the check in your code, you put it in the view, and access the data exclusively through that view. In that way, the check is defined exactly once.

Re: Soft deletion probably isn't worth it

#262

Post by djur » Tue, Jul 19, 2022, 10:55 PM UTC

rodw wrote: post #205

dafelst wrote: post #20

Views are a simple solution to this problem. Pretty much all moderns RDBMSs support updatable views, so creating views over your tables with a simple WHERE deleted_at IS NULL solves the majority of the author's problems, including (IIRC) foreign key issues, assuming the deletes are done appropriately. I feel like a lot of developers underutilize the capabilities of the massively advanced database engines they code ag…

Seriously. That "Downsides: Code leakage" point is nonsensical. ``` CREATE OR REPLACE VIEW active_customer AS SELECT * FROM customer WHERE deleted_at IS NULL OR deleted_at There, I fixed it. Just use `active_customer` instead of `customer ... deleted_at IS NULL`. In fact, since the deleted_at column is a timestamp, the original "leakage" query: ``` SELECT * FROM customer WHERE id = @id AND deleted_at IS NULL; ``` is…

The query isn't broken. In the Rails community at least it is very common to use a nullable frobbed_at column to indicate both "was it frobbed" and "when was it frobbed". In that context, the boolean check is always NULL/NOT NULL, rather than a time comparison.

Re: Soft deletion probably isn't worth it

#263

Post by kleer001 » Tue, Jul 19, 2022, 10:56 PM UTC

Yea, it is.

Re: Soft deletion probably isn't worth it

#264

Post by nightpool » Tue, Jul 19, 2022, 10:59 PM UTC

joshmanders wrote: post #231

rjzzleep wrote: post #170

Earlier quoted context omitted.

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.

What percentage of production Node.js systems use Adonis? It's probably vanishingly low. Laravel is nice, and it's been gaining a lot of adoption in new applications, but the GP said "90s PHP" for a reason. Modern Node JS backends are often littered with hand rolled SQL queries, poor MVC separation, and lots of shoddy, half baked model layers—often without using any library whatsoever. Which is a real shame, because I personally really love programming in JavaScript, and the performance is great, but the strength of Rails as a framework draws me back in every time.

Re: Soft deletion probably isn't worth it

#265

Post by nightpool » Tue, Jul 19, 2022, 11:00 PM UTC

wst_ wrote: post #236

wnevets wrote: post #182

Earlier quoted context omitted.

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?

Yes.

Re: Soft deletion probably isn't worth it

#266

Post by viiralvx » Tue, Jul 19, 2022, 11:00 PM UTC

I don't know if I 100% agree with this blog post. Additionally, having foreign key constraints isn't a "catch-all" solution and breaks at scale. There's frameworks like Rails that can still handle these discards for the user via the `dependent` option on the model with some extra code.

At my current employer, we noticed that `acts_as_paranoid`'s default behavior was not what we wanted, so we migrated over to `discard`. We also added a concern that reflects on dependent associations, finds if they are discardable, and discards them if possible. And that cascades down, easing those concerns. This `Discardable` concern is automatically added to every single soft-deletable model and it has been working out great for us.

[1]: https://github.com/jhawthorn/discard

Re: Soft deletion probably isn't worth it

#267

Post by necovek » Tue, Jul 19, 2022, 11:01 PM UTC

taeric wrote: post #195

necovek wrote: post #185

Earlier quoted context omitted.

And yet another part is making deletes (appear) instantaneous: useful when it involves cleaning up a bunch of "related" data possibly living on different services (eg. S3, ES...). This also helps with the original goal of making them safer by manually implementing "eventual consistency" for data living outside the transactional world.

Don't make deletes appear instantaneous? If you have heavy weight systems, then it makes sense for provisioning and deleting entities is a process, that should be open to monitoring.

Exposing details of long lived background processes, and especially deletion processes to users (who in many cases couldn't care less) is a lot of work that's probably not worth it for the rare "hey, something went wrong" case — it's usually perfectly acceptable to raise that with the support team and let them use internal tools to debug and investigate.

I am sure there are cases where it is worthwhile, but most of the times I've hit this in common web apps, it wasn't.

Re: Soft deletion probably isn't worth it

#268

Post by twelve40 » Tue, Jul 19, 2022, 11:04 PM UTC

alerighi wrote: post #216

gmiller123456 wrote: post #172

Earlier quoted context omitted.

The author uses the "no one ever undeleted anything" as the primary justification. I think this is the part they miss. I've never undeleted a user either, but there have been many times I've gone back to look at something. Either a complaint finally gets around to me as to why the user wanted their account deleted (e.g. feature not working) and it helps to figure out why. Or they're returning and want things set up l…

It may be convenient, but under the GDPR is illegal. When an user deletes an account, all the personal data associated with that user must be deleted (or anonymize it in a way that it's no longer possible to associate it back to the particular user). You cannot just keep user information forever "just in case" they are useful again.

You can most definitely keep around the non-PII data you've generated for that user in your app, such as synthetic user ID's and other stuff. Furthermore, for some apps (fintech) in some countries (US) you are actually obligated to keep around certain information for several years. It really doesn't have to be all or nothing.

Re: Soft deletion probably isn't worth it

#269

Post by astura » Tue, Jul 19, 2022, 11:08 PM UTC

>so you can be left with your customer being “deleted”, but its invoices still live.

This not a problem, its is almost always what's desired, otherwise you have no records for, for example, the tax auditor.

Obviously when, say, an employee leaves basically all things they did on a corporate system can't disappear. Any documents they created/updated still need to be accessed, their git history/commits can't disappear.

When you switch classrooms you don't want all the events that ever happened in the old classroom to disappear.

This sort of systems are the kinds of systems I've worked with my entire career. Undeletion happens all the time too (employees get rehired, for example).

Most computer systems aren't B2C free social media sites where you CAN just delete anything you want because no data is important.

Re: Soft deletion probably isn't worth it

#270

Post by nightpool » Tue, Jul 19, 2022, 11:09 PM UTC

doctor_eval wrote: post #261

madisp wrote: post #229

Earlier quoted context omitted.

I'd argue that the simple `deleted_at IS NULL` check is not broken - unless your product / domain specifically allows and requires scheduled future deletions adding such logic can easily introduce bugs. For example, you could to get the comparison flipped by accident, and if it's only in one place out of many that bug could go unnoticed for a while.

You don't put the check in your code, you put it in the view, and access the data exclusively through that view. In that way, the check is defined exactly once.

And now your view is based on an unstable function, so it's impossible to write partial indexes for (very important for performance!) and impossible to use foreign keys with. Just add a check constraint that deleted at is never in the future and move on with your life. If you really, really need to schedule a delete, make it its own concern (UserVersions table with applicable_at?), don't mix it with your soft delete logic.