YAGRI: You are gonna read it • Hacker News Board

Re: YAGRI: You are gonna read it

#91

Post by ltbarcly3 » Thu, Apr 24, 2025, 7:08 AM UTC

This is good advice except for deleted_at. Soft deletion is rarely smart. Deleted things just accumulate and every time you query that table is a new opportunity to forget to omit deleted things. Query performance suffers a lot. It's just a needless complexity.

Instead, just for the tables where you want to support soft delete, copy the data somewhere else. Make a table like `deleteds (tablename text not null, data jsonb not null default '{}')` that you can stuff a serialized copy of the rows you delete from other tables (but just the ones you think you want to support soft delete on).

The theory here is: You don't actually want soft delete, you are just being paranoid and you will never go undelete anything. If you actually do want to undelete stuff, you'll end up building a whole feature around it to expose that to the user anyway so that is when you need to actually think through building the feature. In the meantime you can sleep at night, safe in the knowledge that the data you will never go look at anyway is safe in some table that doesn't cause increased runtime cost and development complexity.

Re: YAGRI: You are gonna read it

#92

Post by begueradj » Thu, Apr 24, 2025, 7:21 AM UTC

silisili wrote: post #88

I don't like general advice like this, because it's too general. For many, it's probably good advice. For others, not so much. Anyone who has worked at a small company selling to large B2B SaaS can attest we get like 20 hits a day on a busy day. Most of that is done by one person in one company, who is probably also the only person from said company you've ever talked to. From that lens, this is all overkill. It's no…

>I don't like general advice like this, because it's too general. For many, it's probably good advice. For others, not so much.

That's true for any other good advice you may have heard of.

Re: YAGRI: You are gonna read it

#93

Post by nine_k » Thu, Apr 24, 2025, 7:33 AM UTC

motorest wrote: post #79

arialdomartini wrote: post #77

While I like the YAGRI principle very much, I find that adding - updated_at - deleted_at (soft deletes) - created_by etc - permission used during CRUD to every table is a solution weaker than having a separate audit log table. I feel that mixing audit fields with transactional data in the same table is a violation of the separation of concerns principle. In the proposed solution, updated_at only captures the last cha…

Event sourcing also works great. You don't need an audit log per se if you already track a history of all commands that introduced changes to your system.

Event sourcing and "the right to be forgotten" are not always easy to marry.

Re: YAGRI: You are gonna read it

#94

Post by Aldipower » Thu, Apr 24, 2025, 8:23 AM UTC

Five years ago everybody would lough about "soft deletes" or "marked as deleted". Whoever thought this is a good idea from a data protection perspective? You also lying in the face of your users with such a behavior. Shame.

Re: YAGRI: You are gonna read it

#95

Post by nexo-v1 » Thu, Apr 24, 2025, 8:39 AM UTC

Shipped and supported enough startup apps to learn this the hard way: users will delete things they shouldn’t, and you will be asked to explain or undo it. Soft deletes and basic metadata (created_at, deleted_by, etc.) have saved me multiple times — not for some future feature, just for basic operational sanity.

Re: YAGRI: You are gonna read it

#96

Post by damnitbuilds » Thu, Apr 24, 2025, 8:47 AM UTC

crazygringo wrote: post #60

These are not decisions that should be taken solely by whoever is programming the backend. They need to be surfaced to the product owner to decide. There may very well be reasons pieces of data should not be stored. And all of this adds complexity, more things to go wrong. If the product owner wants to start tracking every change and by who, that can completely change your database requirements. So have that conversa…

Yes. Adding fields to a DB is not a risk-free thing a programmer should just do.

Re: YAGRI: You are gonna read it

#97

Post by tliltocatl » Thu, Apr 24, 2025, 8:47 AM UTC

Aldipower wrote: post #94

Five years ago everybody would lough about "soft deletes" or "marked as deleted". Whoever thought this is a good idea from a data protection perspective? You also lying in the face of your users with such a behavior. Shame.

Except almost every database (and most storage devices nowadays) works this way - mark an entry as deleted, then batch delete a lot of entries during garbage collection. It's fundamentally impossible to efficiently erase a record from the middle of a file, except maybe by using an encryption tree, which would still be fairly inefficient.

Actually erasing data is quite hard. Soft deletes doesn't add any new lies, they just move the lies to the upper layer.

Re: YAGRI: You are gonna read it

#98

Post by IshKebab » Thu, Apr 24, 2025, 9:02 AM UTC

Yes! Why something happened is incredibly important. Gitlab made this mistake hard. We have a medium sized instance with some complex CI pipelines and often they'll just get cancelled and it doesn't say why or even who by. And anyone can do it! The only option is to ask the entire company "did anyone cancel this?"

Re: YAGRI: You are gonna read it

#99

Post by optician_owl » Thu, Apr 24, 2025, 9:04 AM UTC

It's a terrible post. What it suggests is to turn your head off and follow overly generalised principle. I guess when somebody invent yet another acronym it is a red flag.

Data has its own life cycles in every area it passes through. And it's part of requirements gathering to find those cycles: the dependent systems, the teams, and the questions you need to answer. Mindlessly adding fields won't save you in every situation.

Bonus point: when you start collecting questions while designing your service, you'll discover how mature your colleagues' thinking is.

Re: YAGRI: You are gonna read it

#100

Post by Aldipower » Thu, Apr 24, 2025, 9:08 AM UTC

tliltocatl wrote: post #97

Aldipower wrote: post #94

Five years ago everybody would lough about "soft deletes" or "marked as deleted". Whoever thought this is a good idea from a data protection perspective? You also lying in the face of your users with such a behavior. Shame.

Except almost every database (and most storage devices nowadays) works this way - mark an entry as deleted, then batch delete a lot of entries during garbage collection. It's fundamentally impossible to efficiently erase a record from the middle of a file, except maybe by using an encryption tree, which would still be fairly inefficient. Actually erasing data is quite hard. Soft deletes doesn't add any new lies, they…

Come on. With a manual "marked as deleted" it stays as this forever, it is not deleted and never will, and the "deleted" data lands also in database backups, is still query-able and so on. I do not care if the deleted data stays for a while on disk or in memory as long it will be eventually deleted by the garbage collector and isn't query-able anymore.