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

111–120 of 161 posts

Re: YAGRI: You are gonna read it

#111

Post by bayindirh »

hamandcheese wrote: post #71
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…

Some things are trivial and nearly free - created_at, updated_at. I don't think engineers need to bring trivialities like this to a "product owner". Own your craft.

When the product you're developing is governed by regulations and standards you need to comply, owning your craft is doing things by the book, not adding fields on your own because it might be useful later.

Re: YAGRI: You are gonna read it

#112

Post by Extasia785 »

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…

This entirely depends on the company culture. I worked in teams where every small decision is in the hand of the PO and I've worked in teams where a software engineer is a respected professional enabled to make their own technical decisions. I found the second option to create higher quality software faster.

Also not sure what you mean by additional effort? Created_at, updated_at or soft-deletes are part of most proper frameworks. In Spring all you need is an annotation, I've been using those in major projects and implementation cost is around a few seconds with so far zero seconds of maintenance effort in years of development. At least those fields are solved problems.

Re: YAGRI: You are gonna read it

#113

Post by [deleted] »

KronisLV wrote: post #109

I don't get why all of the big RDBMSes (PostgreSQL, MariaDB/MySQL, SQL Server, Oracle, ...) don't seem to have built in support for soft deletes up front and center? CREATE TABLE ... WITH SOFT DELETES Where the regular DELETE wouldn't get rid of the data for real but rather you could query the deleted records as well, probably have timestamps for everything as a built in low level feature, vs having to handle this wi…

[deleted]

Re: YAGRI: You are gonna read it

#114

Post by exe34 »

Extasia785 wrote: post #112
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…

This entirely depends on the company culture. I worked in teams where every small decision is in the hand of the PO and I've worked in teams where a software engineer is a respected professional enabled to make their own technical decisions. I found the second option to create higher quality software faster. Also not sure what you mean by additional effort? Created_at, updated_at or soft-deletes are part of most prop…

even better, assume soft deletes and inform them this is how delete works - if there's a hard requirement for hard delete, they will tell you.

the hypothetical future programmer is you in two weeks.

Re: YAGRI: You are gonna read it

#116

Post by nine_k »

motorest wrote: post #105
nine_k wrote: post #93

Earlier quoted context omitted.

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

> Event sourcing and "the right to be forgotten" are not always easy to marry. The absolute basics is to support snapshots and event replay. This is hardly rocket science.

If you try to redact a part of the past, it can also affect the present, as any time traveler knows.

Let's assume we want to remove every message related to user A.

A photo by user B got to be the best of the day because it collected most upvotes. Without the A's vote, it's no longer so. The photo also got to become the best of the month because it was later voted as the top from the best-of-the-day entries, and received a prize. Should we now play the message stream without the A's upvote, things are going to end up radically different, or end up in a processing error.

User B was able to send a message to user C, and thus start a long thread, because user A had introduced them. With user A removed, the message replay chokes at the attempt of B to communicate with C.

One way is to ignore the inconsistencies; it deprives you of most of the benefits of event sourcing.

Another way is anonymizing: replace messages about user A with messages about some null user, representing the removed users. This can lead to more paradoxes and message replay inconsistencies.

Re: YAGRI: You are gonna read it

#117

Post by moritzwarhier »

KronisLV wrote: post #109

I don't get why all of the big RDBMSes (PostgreSQL, MariaDB/MySQL, SQL Server, Oracle, ...) don't seem to have built in support for soft deletes up front and center? CREATE TABLE ... WITH SOFT DELETES Where the regular DELETE wouldn't get rid of the data for real but rather you could query the deleted records as well, probably have timestamps for everything as a built in low level feature, vs having to handle this wi…

Maybe my intuition is wrong, but to me this sounds like a violation of the principle of least power.

"Soft deletes" is just a name for a regular write operation, with specific semantics.

Adding a layer of magic to the DB for this doesn't seem right to me.

And applications could have many different requirements for soft deletes, like the article points out. For example, the simplest version would be just a boolean "deleted" column, but it could also be "deleted_at", "deleted_by", etc.

All of these cases require an bunch of code changes anyway, and the more complex ones could interfere with an implementation of this feature at the database level: such a transparent implementation couldn't access app-specific concerns such as user data, for example.

Adding soft deletes to a legacy app that knows nothing about it would only work for a boolean flag and a maybe date-time value, unless the DBMS would also offer triggers for soft deletes etc?

Seems to me to that this capability would make a DBMS much more complicated.

Re: YAGRI: You are gonna read it

#118

Post by 8bitme »

For `updated_at` and `deleted_at` making them nullable and null until touched is incredibly useful.

Answering queries like how many of these were never updated? Or how many of these were never cancelled?

Re: YAGRI: You are gonna read it

#119

Post by motorest »

nine_k wrote: post #116
motorest wrote: post #105

Earlier quoted context omitted.

> Event sourcing and "the right to be forgotten" are not always easy to marry. The absolute basics is to support snapshots and event replay. This is hardly rocket science.

If you try to redact a part of the past, it can also affect the present, as any time traveler knows. Let's assume we want to remove every message related to user A. A photo by user B got to be the best of the day because it collected most upvotes. Without the A's vote, it's no longer so. The photo also got to become the best of the month because it was later voted as the top from the best-of-the-day entries, and rece…

> If you try to redact a part of the past, it can also affect the present, as any time traveler knows.

That's not how snapshots work. You record the state of your system at a point in time, and then you keep all events that occurred after that point. This means you retain the ability to rebuild the current state from that snapshot by replaying all events. I.e., event sourcing's happy flow.

> User B was able to send a message to user C, and thus start a long thread, because user A had introduced them. With user A removed, the message replay chokes at the attempt of B to communicate with C.

Not really. That's just your best attempt at reasoning how the system could work. In the meantime, depending on whether you have a hard requirement on retaining messages from removed users you can either keep them assigned to a deleted user or replace them by deleted messages. This is not a problem caused by event sourcing; it's a problem caused by failing to design a system that meets it's requirements.

Re: YAGRI: You are gonna read it

#120

Post by hypeatei »

KronisLV wrote: post #109

I don't get why all of the big RDBMSes (PostgreSQL, MariaDB/MySQL, SQL Server, Oracle, ...) don't seem to have built in support for soft deletes up front and center? CREATE TABLE ... WITH SOFT DELETES Where the regular DELETE wouldn't get rid of the data for real but rather you could query the deleted records as well, probably have timestamps for everything as a built in low level feature, vs having to handle this wi…

Temporal tables in SQL server fit this use-case[0], I think.

0: https://learn.microsoft.com/en-us/sql/relational-databases/t...

Post reply on HN