I am working on an app and I have already added the paper trail gem (https://github.com/airblade/paper_trail) to track revisions. Now I am thinking that I want to add Paranoia (https://github.com/rubysherpas/paranoia) to soft delete. If I do that I figure I should keep all the uploaded documents associated with the various models. It's not that hard to implement and the down side perhaps is only storage space.
The big plus here is to provide an audit trail for models and an 'oops' option if someone deletes something by accident.
My initial thought is to just implement it without making the ability to rollback etc public but then just have the option to do it later.
1.) Does this seem like a good idea?
2,) Does anyone have experience with this either way?
I think that's a great idea. Having both is a really great way for keeping track of history even if the record was deleted. It's a good safety measure and a lot of businesses need that.
There probably isn't going to be significant amounts of storage used unless you're talking millions of records. At that point, you're well into the multiple gigabytes of storage, but that's relatively easy to handle these days.
I haven't added both into an app for a while, but I don't think there are any gotchas that I can remember. Paranoia is going to simply flag the main record as deleted which should do what you need.
I think that's where I am headed. If I have lots of records / files that means I have lots of paying customers so it's all good.
I guess my question would be at what point would you want to purge a customers data? Let's say they quit and comeback a year later. There could be an advantage to have saved all that for them.
Honestly, I would probably only purge their data on request. Depending on the app, if they cancel their account, you might give them the option to purge or keep their data, but it's another thing for them to have to worry about when they cancel. It might be nice to automatically save it and then only purge if they ask you via support. Really depends on if your users would be unhappy about that approach or not I guess.
Join 29,763+ developers who get early access to new screencasts, articles, guides, updates, and more.