Temporal aspects of RIMBAA databases

Summary

How, in RIMBAA applications, does one deal with 'versions of an object'. That is, versions of one single (one and the same in terms of identity) business object [or object tree]. This is the temporal aspect of persistence.

• 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.
• What is the smallest part that I want to store. Not an object, moving towards R-MIMs. We version the smallest part. Why not a "form", a collection of observations? Changes policy for versioning.
• Atomic: Support the v3 HXIT data type
• Non-atomic: Use object versioning at the persistence layer (see below for best practices)
• 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'
• Note: this issue is not about replacements of objects by different objects through e.g. a RPLC act relationship.
  • Temporal Database (entry in Wikipedia) and "C.J. Date, Hugh Darwen, Nikos Lorentzos (2002). Temporal Data & the Relational Model, First Edition (The Morgan Kaufmann Series in Data Management Systems); Morgan Kaufmann; 1st edition; 422 pages. ISBN 1-55860-855-9.".
• Common pattern (best practice):
  • Use ODS/Archive versioning - i.e. most current record in ODS, older versions in archive (mirror + archive fields). Current record - SINCE column; Archive Record - FROM, TO columns. Each version has a timestamp (SINCE/FROM/TO), a unique ID, and a link from a prior instance to an instance (the 'active instance') which replaces it.
  • The alternative: In-table versioning, makes relational model more difficult, as FKs would be linked to tuple (ID + versionNumber + 'isCurrentVersion')

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...
• Rene: I think the discussion of whether a particular change requires a new object, or can be dealt with by a new version of an existing object is out of scope for RIMBAA. It should be part of the HL7 methodology to identify how one deals with these kinds of changes.

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

1. (From the minutes of the 20091027 out-of-cycle meeting) Presentation: Object Versioning aspect of the PHI Tools (Davide Magni, ItalTBS, Italy). See http://www.ringholm.de/persist/20091027_RIMBAA_PHI_Technology_and_VERSIONING.ppt for slides.
   • Background: see Object_versioning_in_RIMBAA_Applications
   • Davide presents an overview of the "PHI Technology" Toolsuite. Total model driven approach, with model driven application generation as a final step.
     • Versioning is based on state transitions of acts/entities/roles. Especially all revise trigger events. Suspending is a special case, activate -> suspend -> activate, back to a historic clone of the data.
     • Each version has a timestamp, a unique ID, and a link from a prior instance to an instance (the 'active instance') which replaces it.
     • Introduced a new statusCode 'history' to allow for querying on non-historic data.
     • Hibernate Envers release 3.5 contains a versioning listener, will be used by Phi in a next release.
     • Phi has the ability to switch OFF history if the customer doesn't require it.
   • Ewout: this is versioning at a low (i.e. database) level. No new "replaces" act relationship at the application level. Davide: correct.
   • Andy: needing to clone the whole RMIM graph for just a name change carries a high cost. Davide: easy in terms of code. Ewout: subject that deserves attention: What is the smallest part that I want to store. Not an object, moving towards R-MIMs. We version the smallest part. Why not a "form", a collection of observations? Changes policy for versioning. Tom: to go the opposite direction, there is a history-datatype version of all v3 datatypes. Willem: have not implemented this (HXIT/HIST) as a UDT - Willem to research the option to see if this would be feasable. Ewout: versioning at different levels - also " this diagnoses replaces another diagnosis" at business level. Andy: see Temporal Database (entry in Wikipedia) and "C.J. Date, Hugh Darwen, Nikos Lorentzos (2002). Temporal Data & the Relational Model, First Edition (The Morgan Kaufmann Series in Data Management Systems); Morgan Kaufmann; 1st edition; 422 pages. ISBN 1-55860-855-9.".