4 ms·
This is a problem but IMO, the bigger problem is that you create a pit of failure rather than a pit of success because you now have to remember to add "and dele
by kristiandupont 2y ago
This is a problem but IMO, the bigger problem is that you create a pit of failure rather than a pit of success because you now have to remember to add "and deleted_at is null" everywhere and forgetting to do so often doesn't look like a bug until the day some user sees something they thought had been deleted still appear.
- Fire-Dragon-DoL 2y agoPostgres supports rules for rewriting queries
- kristiandupont 2y agoRight. I have never tried those but they sound unappealing to me. I would expect edge cases where they don't work and unpredictable performance implications. But as I said, I have no experience so this is just my imagination.
- setr 2y agotoo much magic for my taste. I think the more proper thing would be to simply use views, and expose the natural absurdity of the design with one-view-per-table.
- deleted 2y ago[deleted]
- remus 2y agoPerhaps it's a scale thing, but I get more "oh crap, I just deleted this thing, can you get it back for me?" requests than I do bug reports about soft deleted records showing up incorrectly. Being able to restore records immediately is a big win imo.
- deleted 2y ago[deleted]
- treve 2y agoBeing able to contact a dev to undelete a record from a database does sound like a thing that's hard to scale. If this happens a lot, it could be worth examining if there's a UX problem.
- sgarland 2y agoSo implement a trash can?
- throw-the-towel 2y agoAnd how would you implement one, if not with soft-delete?
- sgarland 2y agoNo, it’s still a soft delete, but do it so restoration doesn’t require manual action by a dev.
- josevalim 2y agoAuthor here. This can be addressed with PG views. You create a view where deleted_at IS NULL and now you query the view instead. Furthermore, if the view is “updatable” (which is the case when it only has filters), you can also do updates and deletes directly against it, and it all just works. So as long as your ORM/query builder can work with views, you are good to go. I understand many devs want to avoid moving more logic to the database (I also personally avoid stored procedures and similar) but views are quite declarative and simpler to manage than indexes.
- maiku2501 2y agoI haven't used row level security, but wouldn't it be easy to set the table up such that only a dedicated recovery role could select rows that have deleted_at set? Then the view wouldn't even be necessary.