4 ms·
It's not pretty simple though. In particular, if you have any triggers in your API they may need to be deferred until after undo is no longer possible, or have
by kibibu 13y ago
It's not pretty simple though.
In particular, if you have any triggers in your API they may need to be deferred until after undo is no longer possible, or have explicit commits.
Lets say you have the ability to add a user to a group, and they will get an email about it. You accidentally add your boss to the "I hate my boss" group. How do you support undo in this case? Some sort of timeout before sending is really the only valid approach, but where?
One was is to do the deferred part on the client side, but this means closing the browser after adding somebody will mean they won't get notified at all. You really need to have support for undo in the API for this to be meaningful (or the "add to group" api returns a notification ID that you can cancel).
As an aside, I'm pretty sure the inverse of deleting a model is typically going to be far more complex than just recreating it.
Deleting a social network profile, for example, involves deleting all photos, associations, posts, etc. Easier just to deactivate models so you get easy undo, and periodically flush deactivated objects.
- STRML 13y agoYes, you're right; I shouldn't have put the "it's pretty simple" statement just a few sentences after "It's complicated" - clearly, depending on the app, undo functionality can get pretty hard to manage, especially when there are emails or complicated relations involved.