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

121–130 of 161 posts

Re: YAGRI: You are gonna read it

#121

Post by bongripper »

crabmusket wrote: post #75
jfengel wrote: post #41

Earlier quoted context omitted.

I consider booleans a code smell. It's not a bug, but it's a suggestion that I'm considering something wrong. I will probably want to replace it with something more meaningful in the future. It might be an enum, a subclass, a timestamp, refactoring, or millions of other things, but the Boolean was probably the wrong thing to do even if I don't know it yet.

The way I think about it: a boolean is usually an answer to a question about the state, not the state itself . A light switch doesn't have an atomic state, it has a range of motion. The answer to the question "is the switch on?" is a boolean answer to a question whose input state is a range (e.g. is distance between contacts <= epsilon).

[dead]

Re: YAGRI: You are gonna read it

#122

Post by Spivak »

moritzwarhier wrote: post #117
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 "de…

I don't think it's all magic because you have to implement soft deletes in your application layer and it would be nice to have a little DB support for it. It doesn't have to be some big thing, just the ability for selects and such to work only on undeleted elements by default unless you ask for them would be nice so it doesn't pollute your code and make you have to always remember to point the gun away from your foot.

Re: YAGRI: You are gonna read it

#123

Post by crazygringo »

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…

Because it's too dependent on business logic.

Different products will handle soft deletes differently. Which queries need to include soft-deleted rows and which don't? What about different levels of soft deletes, e.g. done by the user (can be undone by user) vs. done by an admin (can't be undone by user)?

Implementing soft deletes yourself isn't hard. Yes you'll have to make a bunch of decisions about how they work in every circumstance, but that's the point.

Re: YAGRI: You are gonna read it

#124

Post by hnthrow90348765 »

moritzwarhier wrote: post #117
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 "de…

>Adding soft deletes to a legacy app

As an aside, I've never found this to be worth it since you have to change too much and re-test everything for minimal user benefit and time savings. The effort is way worse if the code is not great in the first place. It can be a great decision to make before everything is written.

Maybe it's worth it for files which are hard to reproduce, but you can also rely on DB backups to get those back. If people are regularly deleting things they're not supposed to, you're better off removing the user-facing delete actions, limiting the action to specific users, etc.

Re: YAGRI: You are gonna read it

#125

Post by rjbwork »

hypeatei wrote: post #120
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...

Available on postgres as an extension. It's a bit jank and doesn't have language integrated clauses like sql server.

Re: YAGRI: You are gonna read it

#126

Post by PaulHoule »

Spivak wrote: post #122
moritzwarhier wrote: post #117

Earlier quoted context omitted.

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 "de…

I don't think it's all magic because you have to implement soft deletes in your application layer and it would be nice to have a little DB support for it. It doesn't have to be some big thing, just the ability for selects and such to work only on undeleted elements by default unless you ask for them would be nice so it doesn't pollute your code and make you have to always remember to point the gun away from your foot…

I'd argue that what SQL needs is better facilities for code reuse, metaprogramming and such, it ought to give you the tools that you can make something that lets you add something to the language such that you can add

   ... WITH SOFT UPDATES
and it adds to the table definition as well as to the schema that will cause subsequent statements to be rewritten. There's a lot of interesting logic (in the literal sense) in SQL that is hidden by a strange, irregular syntax that is more obvious in other approaches to databases such as Datalog. I think it was little appreciated outside the hardcore semantic web community that you could compile SPARQL + OWL to SQL and get powerful inference facilities. SQL is a great target for metaprogramming precisely because it is not Turing complete and that a code generator doesn't have to think at all about the order that events are sequenced in. It's kinda sad that metaprogramming tools for SQL are almost all pre-Chomsky and pre-dragon book internal DSLs like JooQ and SQLAlchemy which have their charms (JooQ's excellent integration with Java IDEs) but fall short of what could be done with SQL-to-SQL and SQL-to-X transformations.

Stored procedures are great but many shops don't use them for various reasons. It doesn't help that they look like a mix of FORTRAN and COBOL and also come in a few variations from the (better) set-based PL/SQL of Oracle to the (worse) Transact-SQL based stored proc of Microsoft SQL and PostgresSQL. The other day I talked with Krisztián Szabó of

https://schemamap.io/

who developed a compiler that writes stored procs that do database synchronization.

On the other hand, if you've got access to the internals of the frickin' database I think you can do something better than the ordinary application level soft updates. For instance a "customer record" might very well be not just a row in one table but maybe 15 rows in four tables that are inserted in a transaction and you want to be able to undelete them as a unit.

Re: YAGRI: You are gonna read it

#127

Post by PaulHoule »

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…

I've seen product owners who get blindsided every time by this sort of thing.

On the other hand, in some shops there is a dedicated DBA who is in charge of database schemas and possibly everything else. Before it became fashionable to create a "service layer" where people access the database (now database(s)) throw web endpoints, some organizations would put all the database access into a set of stored procedures managed by the DBA. Maybe that's extreme, but in the real world product owners come and go but the database is forever and deserves to have somebody speaking out for its interests.

Re: YAGRI: You are gonna read it

#128

Post by dogleash »

bayindirh wrote: post #111
hamandcheese wrote: post #71

Earlier quoted context omitted.

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.

So what? I've worked places with lots of regulation. Part of every development job is learning the product domain. In that case devs become comfortable with reading standard/law/regulations and anticipating when software implementation might interact with the areas covered.

Sure there were people who's job was to offload as much compliance work from everyone else; by turning it into internal requirements, participating in design discussion and specializing in ensuring compliance. But trying to isolate the development team from it is just asking for micromanagers.

Re: YAGRI: You are gonna read it

#129

Post by marcosdumay »

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…

It's just not bothersome enough to deviate from the standard.

If they did this, nobody would use it. They do lots of more useful things that people don't use because it's not portable.

There's a sibling comment about temporal databases. Those solve a very bothersome problem, so a few people use them. That means that there's a chance soft deletes get adopted as a side effect of a much more complex standard.

Re: YAGRI: You are gonna read it

#130

Post by bayindirh »

dogleash wrote: post #128
bayindirh wrote: post #111

Earlier quoted context omitted.

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.

So what? I've worked places with lots of regulation. Part of every development job is learning the product domain. In that case devs become comfortable with reading standard/law/regulations and anticipating when software implementation might interact with the areas covered. Sure there were people who's job was to offload as much compliance work from everyone else; by turning it into internal requirements, participati…

> So what?

Think before you act. The machine has no brain. Use yours.

> Part of every development job is learning the product domain.

Yes.

> In that case devs become comfortable with reading standard/law/regulations and anticipating when software implementation might interact with the areas covered.

This is what I'm saying, too. A developer needs to think whether what they are doing is OK by the regulation they're flying against. They need to ask for permissions by asking themselves "wait, is this OK by the regulation I'm trying to comply?".

> But trying to isolate the development team from it is just asking for micromanagers.

Nope, I'm all for taking initiatives, and against micromanagement. However, I'm also against "I need no permission because I'm doing something amazing" attitude. So own your craft, "code responsibly".

Post reply on HN