friendly best practices for soft deletion in vanilla convex
Hi all, just curious about this as its coming up in one my projects - I have a SaaS with a similar data model as the convex cloud product (user -> team-> projects)
I remember in convex ENTs there were some nice ergonomics baked in where we could declare a
.deletion("soft") binding to an ent, representing a soft, or scheduled deletion for a row.
It's possible there is documentation about this. I'm just curious about recommended best practices. For example, in the convex cloud product, if I delete my personal account, what happens to the references to this user? (maybe a members table join that would then have a foreign key to a user document that no longer exists). Would you recommend adding a deletionTime or isDeleted property to a row ? And if so, is the juice worth the squeeze implementing a cascading delete for a fairly complex datamodel? What about deleting a team? Maybe these are handled differently based on having to reference later on.
I have webhooks set up in clerk, where clerk users that are deleted are also deleted in convex. It's possible this soft deletion thing should only be implemented for deleting teams or other resources abstracted from a user.
(fun side question: does convex use convex?)
Big thanks.3 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
Can at least respond from my own experience. Soft deletions tends to be a requirement when you're cascading, I use the
isDeleted approach, but deletionTime/deletedAt works just as well and gives you an additional data point that might be useful. Dealer's choice.
Soft deletion is mostly useful for:
- immediately and reactively representing deleted state in the UI while the actual deletion, which may include cascades to children, is still in progress (or scheduled for later)
- capturing and reflecting the deletion intent before proceeding in case actual deletion fails, especially useful for complex cascaded deletes
I personally use soft deletes for any tables whose docs are "parents" in any relations, but in practice I've ended up using it almost everywhere.Awesome. Thanks so much !