4 ms·

Good frameworks or ORMs has hooks that can ensure things happened (e.g. file deletion) BEFORE the final commit. It's very easy to do this nowadays, you don't ha

Good frameworks or ORMs has hooks that can ensure things happened (e.g. file deletion) BEFORE the final commit. It's very easy to do this nowadays, you don't have to implement it yourself. You can't get away without files either. Suggesting that you only need a database for everything implies that you store every type of data in it which is not possible long term. Some type of data just doesn't fit there, especially files.

AgentME 8y ago
Doing the deletion before the commit means that if the commit fails, you're left with a row that refers to a non-existent file. If that's a problem, then it's better do the deletion afterward. And not just "step 1, commit to the database, step 2, erase the file from S3", because a failure between those steps will cause files to be left orphaned on S3. A good system would be to mark the row as having its file soft-deleted, and have a task the regularly looks for rows marked soft-deleted, make sure the file is deleted from S3, and then mark the row as actually deleted.