Message Title

Xj Chen, I'll answer your initial question here but should you have further ones, I'd suggest we have those conversations on the forums or HipChat as they'll not pollute this jira with unrelated discussions and we avoid pinging watchers and such on closed topics.

When using the ValidityAuditStrategy and a record is updated or deleted, the original audit row insert will always set REVEND to null as well as the optionally enabled REVEND_TSTMP field. That particular strategy deals with setting those values in subsequent update statements.

So for example, in a transaction where I remove an element from the element-collection (I persisted in a separate transaction for clarity):

// Happens when I execute entity.getEmbeddables().clear()
DELETE FROM BasicTestEntity_embeddables WHERE BasicTestEntity_id = ?
binding parameter [1] as [INTEGER] - [1]

// Revision entity 
INSERT INTO REVINFO (REVTSMP, REV) values (?, ?)
binding parameter [1] as [TIMESTAMP] - [(a timestamp value here)]
binding parameter [2] as [INTEGER] - [2]

// Create an audit row for the removal of the element-collection element
INSERT INTO BasicTestEntity_embeddables_AUD (REVEND, REVEND_TSTMP, REV, REVTYPE, BasicTestEntity_id, embeddables_ORDER, data) values (?, ?, ?, ?, ?, ?, ?)
binding parameter [1] as [INTEER] - [null]
binding parameter [2] as [TIMESTAMP] - [null]
binding parameter [3] as [INTEGER] - [2]
binding parameter [4] as [INTEGER] - [2]
binding parameter [5] as [INTEGER] - [1]
binding parameter [6] as [INTEGER] - [0]
binding parameter [7] as [VARCHAR] - [data]

// Create an audit row for the modified BasicTestEntity
INSERT INTO BasicTestEnttiy_AUD (REVTYPE, REVEND, REVEND_TSTMP, value, value_MOD, embeddables_MOD, id, REV) values (?, ?, ?, ?, ?, ?, ?, ?)
binding parameter [1] as [INTEGER] - [1]
binding parameter [2] as [INTEGER] - [null]
binding parameter [3] as [TIMESTAMP] - [null]
binding parameter [4] as [VARCHAR] - [value]
binding parameter [5] as [BOOLEAN] - [true]
binding parameter [6] as [BOOLEAN] - [true]
binding parameter [7] as [INTEGER] - [1]
binding parameter [8] as [INTEGER} - [2]

// Set the validity audit strategy values for the element-collection element
UPDATE BasicTestEntity_embeddables_AUD SET REVEND=?, REVEND_TSTMP=? WHERE REV=? AND REVTYPE=? AND BasicTestEntity_id=? AND embeddables_ORDER=?
binding parameter [1] as [INTEGER] - [2]
binding parameter [2] as [TIMESTAMP] - [(a timestamp value here)]
binding parameter [3] as [INTEGER] - [1]
binding parameter [4] as [INTEGER] - [0]
binding parameter [5] as [INTEGER] - [1]
binding parameter [6] as [INTEGER] - [0]

// Set the validity audit strategy values for the BasicTestEntity entity
UPDATE BasicTestEntity_AUD SET REVEND=?, REVEND_TSTMP=? WHERE id=? AND REV<>? AND REVEND IS NULL
binding parameter [1] as [INTEGER] - [2]
binding parameter [2] as [TIMESTAMP] - [(a timestamp value here)]
binding parameter [3] as [INTEGER] - [1]
binding parameter [4] as [INTEGER] - [2]

The key here is the last two operations in this transaction where the UPDATE statements are executed. The first deals with updating the special columns in the element-collection by locating the proper record and setting the 2 column values accordingly. Once the child records have been modified, we lastly update the root entity table.

In a situation where an entity participates in certain inheritance strategies, you may have several entity tables that will be updated to make sure that the two columns are synchronized to support proper partitioning of the table data across that type of table relationship.