461–470 of 514 posts
Earlier quoted context omitted.
You probably want to put the account on hold for a period where it can be undone. And then clean it up after.
Not always possible in a legal way. For example, GDPR compliance.
Earlier quoted context omitted.
Shouldn’t partitioning help with that? (I have no experience with Postgres.)
Only if those partitions are on separate storage, otherwise you have the same number of dead tuples/dirty pages.
Earlier quoted context omitted.
How would you set up a secure audit trail that didn't rely on the application and/or database at some level? A database is fine for an audit trail. But the application shouldn't have permissions to cover up a change. Likewise, the audit trail should record that a record was created, deleted, maybe undeleted, etc and when, by who. Relying only on the "deleted" flag only shows you the current state, not what and when w…
Any tools you recommend here? Or just roll your own with triggers in the database?
Earlier quoted context omitted.
> Using views, stored procedures and other features lets you implement things like soft delete trivially, without it infecting all your application code. That’s great but some of us actually like to write code. Especially Ruby on Rails where soft delete is a breeze if you don’t overthink it and build something the business doesn’t need.
Well, less code means less bugs, but go nuts. I'm just saying that the database is part of the stack. You wouldn't avoid Ruby features "just in case we stop using Ruby" - so why would we avoid using database features? It's up to you how best to assemble the features from your stack. There is a reason we avoided database features in the 90's, which was to avoid database vendor lock-in. This was almost entirely a finan…
I wouldn't avoid Ruby features because the applications I develop are in Ruby and it would require a complete rewrite anyway. I avoid the database because there are development speed advantages to using Rails features. And everything works together nicely assuming you do things the Rails way.
https://github.com/rubysherpas/paranoia
> If a record has has_many associations defined AND those associations have dependent: :destroy set on them, then they will also be soft-deleted if acts_as_paranoid is set, otherwise the normal destroy will be called.
It's convenient.
Earlier quoted context omitted.
What seems to be missing here is the DB tech he is using. On a proper database you can do your "undeleted" with triggers and it's relatively trivial. Nonsense like a "deleted" column on your main data table just seems silly.
I worked at a place that kept all the deleted stuff in their main tables. It turned out over 90% of the rows were deleted. I'm not sure how often something was undeleted, but it was not very frequent. Some of these soft deleted rows were 5+ years old. Archive that crap.
"The concept behind soft deletion is to make deletion safer, and reversible." That's one part. The other part is that in many industries you have regulatory data retention and audit requirements. This is arguably the most valuable and common reason to perform Logical deletes.
I think billions have been spent bridging the gap between “ideal” software and what businesses actually need. Access control is another thing I see developers wanting to simplify or push to implement later, but is actually a key feature.
"The concept behind soft deletion is to make deletion safer, and reversible." That's one part. The other part is that in many industries you have regulatory data retention and audit requirements. This is arguably the most valuable and common reason to perform Logical deletes.
My experience at a few start-ups has been that account deletion just isn't prioritized. It's not a focus when building an MVP. If the application ever gains traction, everyone is then terrified they'll accidentally delete customer data that they never delete anything. It's a shame. As a user, when I delete my account or data in my account, I want you to permanently delete it, not keep it around and just make inaccess…
Earlier quoted context omitted.
I don't know why you're ragging on Node.js users or even PHP for that matter as both ecosystems have this stuff covered too. Also you're comparing language/runtime with an actual framework and then dogging those users... If you want to compare Rails with Node/PHP then I'd suggest comparing with things like Laravel (PHP), Adonis (Node) and you'll find everything you can do in Rails is done in Node/PHP too.
What percentage of production Node.js systems use Adonis? It's probably vanishingly low. Laravel is nice, and it's been gaining a lot of adoption in new applications, but the GP said "90s PHP" for a reason. Modern Node JS backends are often littered with hand rolled SQL queries, poor MVC separation, and lots of shoddy, half baked model layers—often without using any library whatsoever. Which is a real shame, because…
For all tables containing a BOOLEAN column it’s always possible to simply split this table into two separate tables with the same columns, where the name of the table signals whether the factored-out BOOLEAN column would be TRUE or FALSE.
My gut instinct says it’s cleaner to have two separate tables, but I’ve never found a definite answer.
Earlier quoted context omitted.
Stop spreading misinformation. Nobody is required to hard delete the very second the [delete] button is pressed. You're following the law as long as that mentioned reaper job exists and runs at least once per month, to be safely within the allowed timeframe
I didn't see a claim that deletion had to be "the very second the [delete] button is pressed". This is the actual text of the law[1]: > The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay There is a one month limit of the right of access [2] and right to be informed [3], which flow into some of the articles of the law; and certain…