Cleaning Up Application Data

Cleaning up application data involves removing data from the IEGEXECUTIONSTATE database table and the Datastore(DS) where appropriate. This section details the manual and automatic data clean-up tasks that script authors should be aware of, and makes some recommendations to ensure cleaning up application data can proceed smoothly.

In order to support execution of an IEG script, information about individual script executions must be maintained by the IEG engine. For example the IEG engine must keep track of the current page for the script execution. The IEG engine must also maintain a list of the pages that have been presented to the user to support navigation. The answers to control questions are not persisted in the DS and the IEG engine must also keep track of these. All the information to support the execution of an IEG script is persisted in the IEGEXECUTIONSTATE table. When a new IEGScriptExecution object is created via the IEGScriptExecutionFactory API a corresponding entry is created in the IEGEXECUTIONSTATE table. The IEGEXECUTIONSTATE table is an "internal" table only intended to be used by the IEG engine and it should not be modified or extended. Script authors should not become dependent on or make assumptions about the contents of this table as they can be subject to change without notice.

IEG has no way of knowing when an entry in the IEGEXECUTIONSTATE table is no longer required and therefore the entries will persist until they are explicitly deleted. To avoid the IEGEXECUTIONSTATE table becoming unnecessarily cluttered, if a script execution has completed or will not be resumed or re-executed its entry in the table should be removed via the removeScriptExecutionObject method of the IEGScriptExecutionFactory API.

IEG cannot make any inference as to what data can be used to logically and uniquely identify a particular script execution as this can vary from script definition to script definition. The only way for IEG to identify a script execution is via the generated ID that is assigned to the script execution when it is initially created. It is highly recommended that script authors implement a mechanism to identify script executions by associating unique data with the script execution IDs. A new table can be created to maintain the relationship between the data that identifies the execution and the execution ID to make it easy for script executions to be resumed. When they are no longer required they can be removed. Removing a script execution does not cause any of the gathered data that is persisted in the DS to be removed.

Similarly to IEGEXECUTIONSTATE, the IEG engine and the DS have no way of knowing when the data that is gathered during a script execution and persisted in the DS is no longer required. Again, the DS can become unnecessarily cluttered with entities that are no longer required. It is intended that entities will not persist in the DS indefinitely but that the gathered data be moved to application tables and then removed from the DS. When an entity is deleted from the DS its child entities are also deleted. Therefore when the data that is gathered during a script execution has been moved to application tables and is no longer required it is sufficient to delete the root entity for the execution.

The following example code snippet shows the deletion of the root entity:

Figure 1. Deleting the Root Entity
final Long applicationID = execution.getRootEntityID();
      final Entity rootEntity = datastore.readEntity(applicationID);
      rootEntity.delete();