Temporal aspects of RIMBAA databases

Summary

How, in RIMBAA applications, does one deal with 'versions of an object'.

• If you receive an update of an object, should the old object be simply overridden and the new one persisted? Or should the history of the object be maintained? Other objects may reference a specific (old) version of the object.
• This is related to the (potential) requirement to archive ControlActs - to keep a record of who has caused certain changes to happen.
• See also the Core Principles document on 'Accountability'

Analysis

• Ewout Kramer: Are we even talking about "versioning"?. I guess that as soon as an Act has been "active" and communicated to other systems (or users) you just cannot simply change it, even if you have a versioning database like Hibernate Envers. You are really replacing a previous Act with a new one (with a new Id!), possibly indicating this using a "RPLC" ActRel and putting the original Act to sleep ("obsolete") AND notifying interested parties of this change. The other case might be where your Act has not yet been communicated or "active", but still "new". The record would be considered "under construction" and you could probably just change anything without much ado. This might be different for "registry" kind of things, like telecom addresses in Roles and so on, where you do not really replace Roles like you do with acts. Here, HXIT support for updates or Hibernate Envers might be the way to go. Aside from technique, somebody making up his mind and changing opinions is not correcting an older Observation, he is stating a new Observation. This is probably different from correcting an erroneous entry of an Observation, but can we really make this difference in a UI? Will there be a "grace period" during which you can change your mind? Can you do this until you "activate" your Act? This still is completely different from an address change. Here I think the validity of the old data just ends, but it wasn't incorrect before. You are also not changing you mind about the address, there just is a new address..... so I thing we have multiple concepts of change here, which will require a different method of solving...

Discussion

• Davide Magni: we are taking in to account the new "framework" from jboss to manage the history.. will be relaese with hibernate 3.4