Hacker News Reader

Comment by AlexeyMK | Hacker News Reader

You can get around the "check in every transaction" problem with an ORM, but now you're (more) coupled to your ORM which you will occasionally inevitable need to circumvent for something or other. And now you've made it (more of a) leaky abstraction.

View on HN

or you can create view for every table that supports soft deletion and ensure all of your read-only queries are using those table

    CREATE VIEW current_customers AS
        SELECT * FROM customers where deleted_at is null;

    SELECT * FROM current_customers JOIN ...

Of course, this comes with its downsides e.g. views need to be recreated in every migration and there might be some complex join operations that might not work.

It may be work sometime in the future, but having to prefix every query with a null check sounds bonkers. A view can be optimised to do all that for you. I made the what the flip expression reading that they did a prefix on everything.

It can be the other way around, that the table has prefix/suffix, and the view doesnt. Alternatively view can be created with the same name, but in a different schema, which is set with higher priority for the user (e.g. via search_path in PG)

Bwttwr yet, encode the logic in a view and run your queries against the view. DRY

Sure, but you need an "undeleted" view per table now - I haven't seen an ORM offer maintaining those views capability out of the box - any to look at?

Don’t forget versions of the schema, and data that is not migrated to the new schema

In postgres you cannot make a foreign-key reference to a view, which effectively means you can't prevent another table from referencing a soft-deleted record.

I wish Postgres had something like a "CHECK contraint" on a foreign key.

There is a hack of sorts. You create a duplicate of the primary key column, named e.g. id_active. You create a CHECK constraint which says something like "(status = 'Deleted' AND id_Active IS NULL) OR (status <> 'Deleted' AND id_active = id)". You create a unique index on "id_active", and point your foreign key to that. When you create a record, populate both id and id_active to same value; when you soft-delete it, set id_active to NULL. Actually, maybe a simpler solution is to make id_active a "GENERATED ALWAYS AS ... STORED" column–although I'm not sure if Postgres supports them for foreign keys? That's a relatively new Postgres feature and I haven't done much yet with the more recent versions in which that feature was added.

I’m also not sure about the foreign key restrictions on generated columns (and glancing at the docs I don’t see anything about it on there) but for all intents and purposes they are real columns so I’d imagine it probably works. Apparently they run after the before triggers, I’m not totally sure where foreign keys are checked but probably after that?

As an aside, they’re a great feature. We’re using them to generate columns that we can index for efficient joins between tables and also for creating text strings for searching over using trigram indexes. The whole thing is really seamless.

I haven't tested it but it might be the case that it'd need to be a stored generated column to be referenced like that but that shouldn't be a big deal.

Might be mistaken but I think Postgres only has stored generated columns at this stage.

You can choose when FKs apply in postgres, including deferring until the very end of the transaction.

I'm not trying to shill for the company I work at, but in Hasura, you can make FK's and relationships between views and treat them like regular insertable/updatable tables.

It was one of the many things that impressed me so much when I was a user that made me want to hack on the tool for a living.

So, this problem of soft-deletes becomes trivial

Reply on news.ycombinator.com