4 ms·

Also if people know that deletion is reversible, they're more likely to actually do it, which can keep things generally tidier. I don't actually like using a "

Also if people know that deletion is reversible, they're more likely to actually do it, which can keep things generally tidier. I don't actually like using a "deleted" column, my standard table has a status column, and deleted is one of those states, along with active/pending/suspended/etc, as the needs dictate. This way I get soft deletes for basically free both in the schema, but also in the queries (which would generally default to active), so it's not really the spaghetti that the author discusses.

robertlagrant 4y ago
That still has the same issues. You have to remember to set every linked table's records to the same state, or remember to query every linked table through the table that has the lifecycle column on it.
- jwarden 4y ago
  Forgetting to include the lifecycle column in your query may mean not understanding what question you are trying to answer with your query.
- dubswithus 4y ago
  There are some Rails gems that take care of this by scoping associations (that also have the deleted_at column).
JohnBooty 4y ago
For some applications this is fine, depending on your app/business logic but for a lot of applications states like active/pending/suspended and "deleted" are not mutually exclusive. Suppose I soft-delete an active, pending, or suspended user using your scheme. Now I need to un-delete the user. What status should they have? We don't know. This is another "best practice" I've learned over the years. Those flags/statuses you think are mutually exclusive? Maybe they aren't. Or maybe they are now but won't always be. It's usually easier in the long run to give each status its own column even if you think they'll always be mutually exclusive. Because I mean, what are you really saving? A few bytes per record? In most cases that's not worth it.

4 ms·

Also if people know that deletion is reversible, they're more likely to actually do it, which can keep things generally tidier. I don't actually like using a "

by efsavage 4y ago

robertlagrant 4y ago
That still has the same issues. You have to remember to set every linked table's records to the same state, or remember to query every linked table through the table that has the lifecycle column on it.
- jwarden 4y ago
  Forgetting to include the lifecycle column in your query may mean not understanding what question you are trying to answer with your query.
- dubswithus 4y ago
  There are some Rails gems that take care of this by scoping associations (that also have the deleted_at column).
JohnBooty 4y ago
For some applications this is fine, depending on your app/business logic but for a lot of applications states like active/pending/suspended and "deleted" are not mutually exclusive. Suppose I soft-delete an active, pending, or suspended user using your scheme. Now I need to un-delete the user. What status should they have? We don't know. This is another "best practice" I've learned over the years. Those flags/statuses you think are mutually exclusive? Maybe they aren't. Or maybe they are now but won't always be. It's usually easier in the long run to give each status its own column even if you think they'll always be mutually exclusive. Because I mean, what are you really saving? A few bytes per record? In most cases that's not worth it.