Best practice for implementing long-term story mode for O / RM (Hibernate)?

Question

I have mapped several java classes, such as Customer, Assessment, Rating, ... in a database with Hibernate. Now I'm thinking of a historical mode for all changes to persistent data. The application is a web application. In the case of deleting (or editing) data, another user should be able to see the changes and discard them. Since the changes are outside the scope of the current session, I do not know how to solve this problem in the form of the Command pattern, which is recommended for canceling the function.

For editing a single value, an approach like this question sounds fine. But what about deleting an entire permanent object? The easiest way is to create a flag in the table if this client is deleted or not. The most difficult way is to create a table for each class where deleted objects are stored. Is there something in between? And how can I integrate these two things into the O / RM system (in my case Hibernate) comfortably, without much noise with SQL (which I want to avoid due to portability) and is still flexible enough?

Is there any best practice?

Answer 1

One way to do this is to have a “change history” object with properties for the identifier of the entity of the object, changed, action (change / delete), property name, original value, new value. Perhaps also a link to the user performing the editing. Deletion will create entities for all properties of the deleted object with the action "delete".

This object will provide enough data to execute the undo and view the change history.

Answer 2

One approach to maintaining audit / revocation routes is to mark each version of an object record with a version number. Finding the current version would be a painful effort if it were a simple version number, so reverse version numbering works best. "version" 0 is always current, and if you do an update, version numbers for all previous versions increase. Object deletion is performed by increasing version numbers in current records and not inserting a new one into 0.

Compared to the attribute-by-attribute approach, this makes much simpler rollbacks or historical versions, but takes up more space.

Answer 3

Hmm, I'm looking for an answer too. So far, the best I've found is the structure www.jboss.org/envers/, but even this seems to me more than necessary.