I really don’t like having “deleted” flags and such on database records. I thought about using elixir processes to schedule a deletion with
:timer.sleep, and sending a kill message if the user clicks the undo button. Are there obvious drawbacks to implementing “undoable” actions this way?
# Schedule the deletion
pid = spawn(fn -> :timer.sleep(10_000); Posts.delete(post) end)
# User clicks the undo button
Two things jump out at first glance:
- what happens if the user wants to undo but loses the race? At that point the system has deleted a record they WANT back
- what happens if the system goes down (for instance, because a new version has been deployed) during that 10-second period? At that point the user requested something be deleted but it will NEVER happen
Yeah actually I’m thinking, especially because of the nature of the application, it might be better to change the logic to something more similar to “hide from feed” or “archive.”
As a side-note, is there some way to prevent the second case from happening without persisting the actions to disk somehow?
Not really no.
More to the point though, I’m not sure that the code here does what you want it to do. It won’t delete the records until 10 seconds in the future at all, which means if your user loads the page in another tab, the records will still show as not deleted.
A more traditional way to do this is to have a
deleted_at column that you set immediately to
NOW() when the user clicks delete. If you want to actually remove the rows at a future point you can clean it up later.