This is a very common feature in software, and I am sure there is a whole deal written about it, but I really don't know what the technical term is, so here I am:
I am talking about giving your service or product the ability to save the state of some data to be able to access it in the future and rollback changes. This would create a history a changes as well as a collection of saved states or backups (although not necessarily used as a backup, just as an "undo" action feature).
The scenario would be having a feature that interact with multiple objects and we want to save the state they have at that specific moment so that we can rollback to that point at any moment.
Points to consider:
objects are of different types and they may be related to each other
not all information held in an object is necessarily relevant when it comes to saving its state. For instance, when saving the state of
timeare relevant but
locationis not (the beach is going nowhere).
we would have to decide the level of detail of the saving action. Going for small changes would create a great overhead. But going for bigger changes would reduce the level of detail to which the system would apply, of course. I would prefer the latter though.
How should I approach this?
what would be an appropriate design for the state saving system?
what would be an appropriate design for the state restoration system?
what would be an adequate persistence system? Go with your database as usual? Or perhaps serialize the data and save it as a binary file? (I guess this is a bad idea)
About the last point: if we were to use the database (99% sure this would be the way to go) would we use the same tables or create dedicated ones for the restoration system? I can see pros and cons about both decisions.