1

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 Beach things like temperature or time are relevant but location is 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.

2

On a database level the technical term would be "transaction". But this isn't meant for application level features, and should only be used for rollback in case of errors.

For a complex scenario you might want to go with a database layout that follows the principles of Slowly Changing Dimensions

If you are free in your technology choice and have some time on your hands you could look into Datomic which is a database built in Clojure, that among other features provides full historization, which makes it relatively easy to implement "Undo"-like features.

Another thing to take a look at might be Event Sourcing - a design pattern that can at any time reconstruct the current state by replaying events.

  • A graph database could also serve. An node's history would be a linked list, head of which will be the latest version, connected to other nodes. – S.D. Sep 28 '18 at 7:34
  • Unfortunately I have to work with the database I have. – dabadaba Oct 1 '18 at 12:46
0

For less complex cases (like a single table), one would have the main table that stores the current record(s), and then a separate table that stores all the historical records with a FK to the main tables current record. It's easy to update current and store a new record in historical.

For complex sceanarios (many objects and relations), storing the entire state in some form (JSON, XML, Binary, etc.) can be used. In this case, only one record is needed for storage as that record stores the entire structure of data which includes primary and secondary data relations. To restore, just apply the data to the table(s) as needed and store a new blob of the new state.

I don't know your exact requirements but I've seen both methods used in the past.

  • Would the complex scenario be stored as json/xml/binary files or as blob in the database? I've never really used this data type in a database so I am not sure to what point this is a good idea – dabadaba Oct 1 '18 at 12:54
  • You could store it in the database if you want or on in the file system. Some database use the file system to store it anyway and use a pointer type of object in the db. – Jon Raynor Oct 1 '18 at 14:05
  • What would be the differences between storing it as a file or as a blob in the db? Any downside to either? – dabadaba Oct 2 '18 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.