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

Avoiding the soft delete anti-pattern

cultured.systems

Post reply on HN
Print view View original

41–50 of 61 posts

Re: Avoiding the soft delete anti-pattern

#41

Post by AdrianB1 »

GMoromisato wrote: post #36

Isn't soft-delete just a variant of having a lifecycle? The article tries to distinguish it by saying that the lifecycle pattern is implemented at the app-layer instead of the database layer, but isn't their criticism of soft-delete that the app-layer has to deal with it? Maybe a better recommendation is to give guidelines for implementing soft-delete?

I have the same struggle figuring what the author wants to say about this. The difference between a soft delete and a lifecycle, in the context of the article, is just semantic.

Re: Avoiding the soft delete anti-pattern

#42

Post by Scubabear68 »

I am surprised the article didn’t mention the obvious fix soft deletes potential performance issues - have a job run regularly that archives soft deleted data older than X units of time.

This allows for undoing a soft delete and gets rid of soft deleted rows eventually.

Re: Avoiding the soft delete anti-pattern

#43

Post by AdrianB1 »

For some reasons I was involved a lot with databases in the past 5 years (more than usual) and I don't remember to meet soft-delete implemented anywhere, but lifecycle is used almost everywhere. I think that soft delete may be an indicator of bad design.

Re: Avoiding the soft delete anti-pattern

#44

Post by Isamu »

000ooo000 wrote: post #9

So we call approaches 'anti-patterns' now if they aren't universally suitable?

There was the software “pattern” hype back in the 90’s, people began to think of the word “pattern” as meaning “good”. So there was some discussion of what to call a bad pattern, and people decided they liked “anti-pattern”.

So, not the opposite of a pattern, but the opposite of good. There you have it.

Re: Avoiding the soft delete anti-pattern

#45

Post by schwede »

AdrianB1 wrote: post #41
GMoromisato wrote: post #36

Isn't soft-delete just a variant of having a lifecycle? The article tries to distinguish it by saying that the lifecycle pattern is implemented at the app-layer instead of the database layer, but isn't their criticism of soft-delete that the app-layer has to deal with it? Maybe a better recommendation is to give guidelines for implementing soft-delete?

I have the same struggle figuring what the author wants to say about this. The difference between a soft delete and a lifecycle, in the context of the article, is just semantic.

I think the idea is you could still have a page in the UI that shows archived data but you wouldn’t do that normally with a soft delete. The lifecycle thing makes it up front with the user instead of hiding soft delete as an implementation detail.

Re: Avoiding the soft delete anti-pattern

#46

Post by kadoban »

Scubabear68 wrote: post #42

I am surprised the article didn’t mention the obvious fix soft deletes potential performance issues - have a job run regularly that archives soft deleted data older than X units of time. This allows for undoing a soft delete and gets rid of soft deleted rows eventually.

Can't you just use a partition too?

Re: Avoiding the soft delete anti-pattern

#47

Post by banish-m4 »

The choices are:

A. Move deleted data to (an)other table(s): users, deleted_users

B. Read from a scope, view, or materialized view but update a raw table: deleted bool or deleted_at datetime

C. Sprinkle conditionals everywhere live data is desired: deleted bool or deleted_at datetime

There is no one "the way" for all use-cases.

Re: Avoiding the soft delete anti-pattern

#48

Post by meatmanek »

GMoromisato wrote: post #36

Isn't soft-delete just a variant of having a lifecycle? The article tries to distinguish it by saying that the lifecycle pattern is implemented at the app-layer instead of the database layer, but isn't their criticism of soft-delete that the app-layer has to deal with it? Maybe a better recommendation is to give guidelines for implementing soft-delete?

As I understand that section: if the data you're dealing with already has a need for some sort of lifecycle that's fairly prominent in your data model (i.e. where you're likely to be filtering based on the lifecycle column in all your queries anyway), then adding a lifecycle state for "deleted" is perfectly fine.

Re: Avoiding the soft delete anti-pattern

#49

Post by to11mtm »

EdwardDiego wrote: post #26
nivertech wrote: post #25

Earlier quoted context omitted.

The problem is that people’s first choice is to use generic models like CRUD/CRUD-L/REST/etc., instead of unvesting a bit of time in upfront thinking/design and building a custom model. IMO, if entity might be resurrected/revived/“undeleted”, then it either cannot be killed/deleted, or more likely what you thought as “deletion” was something else (e.g. suspending, archiving, hiding, or putting into trash bin). It’s b…

I've never seen it done well, and yeah, it sounds good in theory, in reality, blurgh.

I've seen it done fairly well, or at least 'doable if wanted but not turned on'.

IME, ideal state is that 'soft deletes' are kept primarily for easing debugging, and the 'soft delete' is kept until archival of soft deleted events occurs (also primarily for debugging/compliance, but sometimes having 'recent data' closer to runtime makes debugging cycles easier...

The biggest problem in doing so successfully is getting the design of things right, which is hard to get buy-in on.

Re: Avoiding the soft delete anti-pattern

#50

Post by to11mtm »

wruza wrote: post #6

It’s a great article exploring the idea, but the premise and arguments leading to it are somewhat weak, imo. First, views aren’t “fragile”. I may be wrong here, but it feels like TA tries to squeeze that along with some abstract-ORM issues. Second, “anti-pattern” is a very technical rating of this phenomenon. Business logic and its databases may contain data that may, may not, or can never be viewed as deletable, at…

> abstract-ORM issues

People get so attached to ORMs with object tracking that they invent whole categories of blog articles to work around cases where a simpler abstraction would be less work.

Post reply on HN