Operation Execution Recording
Overview
Each repository object has operationExecution multi-valued container that contains information
on recent operations executed on this object.
There are basically three reasons for that:
-
To see recent modifications of an object, along with some basic context (initiator, task, etc).
-
To see recent failures occurred when an object was processed by a task.
-
To be able to repeat processing for objects that failed to be processed by a task.
The operation execution records are of two kinds:
-
Simple operation execution records represent modifications that were done at a target object.
-
Complex operation execution records represent the processing of a source object by a task.
| The nomenclature should perhaps change some day. |
The simple records support reason number 1: They inform about recent modifications on a target object. The complex records support reasons 2 and 3. It is possible to look up objects that failed to be processed, and either display them, or retry the processing.
Managing operation execution records
In order to prevent growing objects indefinitely, we do a regular cleanup of operation execution records. The rules are as follows:
-
Simple and complex records are treated separately.
-
After processing an object by a task, all results related to that task before the task last started are deleted. This allows having more than one record for given task, e.g. for multi-part tasks. [1]
-
Usual limitations by age and number of records apply.
| Do we really want to separate simple and complex records when considering task OID? We could end with simple record originating in given task run, and a complex record from later task run. That could cause some confusion. (Or maybe not, it depends.) |
TODO finish …