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

YAGRI: You are gonna read it

scottantipa.com

Post reply on HN
Print view View original

11–20 of 161 posts

Re: YAGRI: You are gonna read it

#11

Post by swagasaurus-rex »

evanmoran wrote: post #10

Just curious, how do people feel about this general style of soft deletes currently? Do people still use these in production or prefer to just delete fully or alternatively move deleted rows to a separate tables / schema? I find the complexity to still feel awkward enough that makes me wonder if deleted_at is worth it. Maybe there are better patterns out there to make this cleaner like triggers to prevent deletion, s…

I think soft deletes using timestamptz are a good thing.

Deleting rows directly could mean you're breaking references. For example, say you have a product that the seller wants to delete. Well, what happens if customers have purchased that product? You still want it in the database, and you still want to fulfill the orders placed.

Your backend can selectively query for products, filter out deleted_at for any customer facing queries, but show all products when looking at purchase history.

There are times when deleting rows makes sense, but that's usually because you have a write-heavy table that needs clearing. Yes, soft-deletes requires being careful with WHERE statements filtering out deleted rows, but that's a feature not a bug.

Re: YAGRI: You are gonna read it

#12

Post by tcdent »

arjonagelhout wrote: post #3

A little while back, I had a conversation with a colleague about sorting entries by "updated at" in the user interface, and to my surprise this was not added by the backend team. Many of these "we are going to need it"s come from experience. For example in the context of data structures (DS), I have made many "mistakes" that I do correctly a second time. These mistakes made writing algorithms for the DS harder, or ma…

Database schemas being perfect out-of-the gate was replaced by reliable migrations.

If it's not data that's essential to serving the current functionality, just add a column later. `updated_at` doesn't have to be accurate for your entire dataset; just set it to `NOW()` when you run the migration.

Re: YAGRI: You are gonna read it

#13

Post by ffitch »

curious that both YAGNI and YAGRI arguments could realistically be made for the same fields. guess it boils down to whether someone’s YAGRI is stronger than their colleague’s YAGNI ( :

Re: YAGRI: You are gonna read it

#14

Post by imcritic »

evanmoran wrote: post #10

Just curious, how do people feel about this general style of soft deletes currently? Do people still use these in production or prefer to just delete fully or alternatively move deleted rows to a separate tables / schema? I find the complexity to still feel awkward enough that makes me wonder if deleted_at is worth it. Maybe there are better patterns out there to make this cleaner like triggers to prevent deletion, s…

Always soft-deletion first. Then it gets exported to a separate archive and only then, after some time and may be attempted to be fully deleted from the initial base.

Re: YAGRI: You are gonna read it

#15

Post by SOLAR_FIELDS »

tcdent wrote: post #12
arjonagelhout wrote: post #3

A little while back, I had a conversation with a colleague about sorting entries by "updated at" in the user interface, and to my surprise this was not added by the backend team. Many of these "we are going to need it"s come from experience. For example in the context of data structures (DS), I have made many "mistakes" that I do correctly a second time. These mistakes made writing algorithms for the DS harder, or ma…

Database schemas being perfect out-of-the gate was replaced by reliable migrations. If it's not data that's essential to serving the current functionality, just add a column later. `updated_at` doesn't have to be accurate for your entire dataset; just set it to `NOW()` when you run the migration.

“Reliable migrations” almost seems like an oxymoron. Migrations are complicated, difficult and error prone. I think there’s a good takeaway here around good initial schema design practices. The less you have to morph your schema overtime, the less of those risky migrations need to run.

Re: YAGRI: You are gonna read it

#16

Post by nailer »

I have a different way of thinking about this: data loss. If you are throwing away data about who performed a delete it is a data loss situation. You should think about whether that’s OK. It probably isn’t.

Re: YAGRI: You are gonna read it

#17

Post by imcritic »

tcdent wrote: post #12
arjonagelhout wrote: post #3

A little while back, I had a conversation with a colleague about sorting entries by "updated at" in the user interface, and to my surprise this was not added by the backend team. Many of these "we are going to need it"s come from experience. For example in the context of data structures (DS), I have made many "mistakes" that I do correctly a second time. These mistakes made writing algorithms for the DS harder, or ma…

Database schemas being perfect out-of-the gate was replaced by reliable migrations. If it's not data that's essential to serving the current functionality, just add a column later. `updated_at` doesn't have to be accurate for your entire dataset; just set it to `NOW()` when you run the migration.

Still depends on what the data represent: you could get yourself in a storm of phone calls from customers if after your latest release there's now a weird note saying their saved document was last updated today.

"HOW DARE YOU MODIFY MY DOCUMENTS WITHOUT MY..."

Re: YAGRI: You are gonna read it

#18

Post by zie »

evanmoran wrote: post #10

Just curious, how do people feel about this general style of soft deletes currently? Do people still use these in production or prefer to just delete fully or alternatively move deleted rows to a separate tables / schema? I find the complexity to still feel awkward enough that makes me wonder if deleted_at is worth it. Maybe there are better patterns out there to make this cleaner like triggers to prevent deletion, s…

If you have a good audit log, it really doesn't matter. You can always restore it if need be.

If you have no audit log(or a bad one), like lots of apps, then you have to care a lot.

Personally, I just implement a good audit log and then I just delete with impunity. Worst case scenario, someone(maybe even me) made a mistake and I have to run undo_log_audit() with the id of the audit log entry I want to put back. Nearly zero hassle.

The upside, when something goes wrong, I can tell you who, what and when. I usually have to infer the why, or go ask a human, but it's not usually even difficult to do that.

Re: YAGRI: You are gonna read it

#20

Post by tcdent »

SOLAR_FIELDS wrote: post #15
tcdent wrote: post #12

Earlier quoted context omitted.

Database schemas being perfect out-of-the gate was replaced by reliable migrations. If it's not data that's essential to serving the current functionality, just add a column later. `updated_at` doesn't have to be accurate for your entire dataset; just set it to `NOW()` when you run the migration.

“Reliable migrations” almost seems like an oxymoron. Migrations are complicated, difficult and error prone. I think there’s a good takeaway here around good initial schema design practices. The less you have to morph your schema overtime, the less of those risky migrations need to run.

My experience over the last decade has been different.

Use a popular framework. Run it against your test database. Always keep backups in case something unforseen happens.

Something especially trivial like adding additional columns is a solved problem.

Post reply on HN