When does it make sense to use forceDelete?

I tend to use soft delete as an archiving mechanism. You can periodically force delete trashed records. You might use deleted records to aggregate data, which is subsequently purged.

There's plenty of reasons when you might delete; the more important question would be what value does soft deleting data present to your application? Why are you keeping things after they're removed and how long is that deleted information valid?

@deringer perfect questions to ask. Two yr old high use app could end up with 10000 plus rows of soft deleted data. Why?

Only time I use it is in data sensitive (which the questions answer) and/or if a lower role can delete but higher role actually deletes.

If you have users, they might want to delete something, yet have the ability to recover if they made a mistake. However, if they close their account you might want to delete all their data.

@ianspangler I use it for deleted calendar entries, the user can go to the recycled bin and take an action over the deleted records, restore some or delete others (forceDelete)

I am working with an application that already has a lot of existing data (it is a live site), but rebuilding it in Laravel. I am intending to use soft delete for at least the following scenarios:

1. A user decides to cancel/ delete their account, including all of their activity. But some months later, they decide to come back, at which point we would like to restore it for them rather than have them start all over...

2. We are asked, by an author/ rights holder, or some other authority, to take down a certain profile immediately. However, we might like to be able to take some time to edit it, removing any offending aspects, and restore it.

Ownership is a tricky issue with this application because, aside from comments and votes, users do not actually have full ownership of the content they publish. There is public editing/ contributions involved and their submissions are technically property of the site according to the terms of service. Hence, if they decide to delete their account, it shouldn't necessarily cascade and delete all of their posts/ profiles. In similar ways, if a user on change.org or Quora decides to delete their account, I am pretty sure, all of their campaigns and questions that people have been supporting or answering for months don't get taken down along with them. But they DO get a line of credit (their name and image) on these profiles. So, figuring out how to handle foreign key constraints is not so straightforward. Would it be advisable to set user_id references to NULL (thereby making these users anonymous) when they decide to officially "leave" the site?

@ianspangler I think with the first option you stated you need to be careful in making it clear to the user that when you're deleting their account, you won't actually be deleting it, and explaining the reason behind doing so. I'd still give them the ability to unequivocally delete their account, though.

If you want to keep the content but not the owner / user of the content, you can delete the record and use onCascade('set null') for the constraint. That way, you can keep the context of any content they wrote, without necessarily attaching their name to it.

Thanks, that makes sense. So I would just need to check if the user_id is set (not null) in my template before displaying a user's name / image.