Relations in Archiving Configuration

As most objects administered by Valuemation are interrelated, the decision to archive objects of a certain object type poses the question which of their related objects should also be archived.

As a general rule, archiving should be approached in a recursive top-to-down fashion. The main archived object type (usually a 'root' object type) will be at the top of the hierarchy, some of its related objects at the second level and some objects related to the related objects further down in the hierarchy in a recursive manner.

The key to proper archiving configuration is in determining which of the related objects should be archived and which should be kept in the main database schema. This is done in the 'Relations' tab of the 'Archiving Configuration' editor.

A brief overview of the 'Relations' tab

The 'Relations' tab of the 'Archiving Configuration' editor contains to following columns and actions:

Columns

• Relation Name

  Name of the relation

• Relation Info

  Relation description

• Number of Children

  Number of further relations one level down the hierarchy

• Delete Rule

  Relation delete rule as defined on the database level. See below for more information.

• Action

  Archiving action to be taken for this relation. By default the action is based on the delete rule but can be overridden - see below for more information.

  If the action column displays 'Error', then foreign key constraint is missing for the relation. In such case it is necessary to first create the constraint in the database. Note that archive configuration containing such relation cannot be set as Enabled.

• Validation Message

  If the analysis of the relations (performed during initial populating of the 'Relations' list or by running the 'Analyze' action) reveals any inconsistencies or problems, a pre-defined description of the problem is displayed in the 'Validation Message' column/field.

Actions

• Edit

  Action 'Edit' opens the relation in an editor in which the 'Action' can be changed and relations one level below examined and edited. Values in the remaining fields of the editor have been supplied by the application and cannot be changed.

• Add Configuration for to-1 Relation

  The action adds a new (to-1) relation to the 'Relations' tab.

  Although usually only 1:n relations with foreign key pointing to the archived parent are important for archiving, in some cases also to-1 relations (even with foreign key pointing from the archived object type to the other related object type) are relevant. Such relations are not by default listed in the 'Relations' tab and need to be added.

The default archiving action

Determining the archiving of all related objects is potentially a very complex task. The application makes the task easier by using delete rules specified for the relations on the database level to automatically determine which related object types should be archived. However, the delete rules may not always be set correctly from the view point of the business logic. If examining the configuration (for instance on the basis of running an archiving simulation) indicates the need to change the default action for a more appropriate one, it is possible to do so:

1. In the 'Relations' tab, call action 'Edit' on the given relation
2. The relation opens in an editor. Use the provided drop-down to change the value in the 'Action' field.
3. Click 'Ok' to save the change and close the editor.

Use the ability to change the default archiving action with caution and on the basis of thorough understanding the given business model. See paragraph 'Delete Rules and Archiving Actions' for background information on delete rules and default action assignment.

Note: The Ticket - Expected Change anomaly

The "normal" way of archiving the relations of objects to other independent objects is to archive the linking objects representing the relations and not to archive the target objects themselves. For example, relations of a ticket to systems will be archived by archiving the ticket-systems linking objects but not archiving the system objects.

A known exception to this rule exists in standard Valuemation - the link of a ticket to expected changes. In this case not only the linking object 'tckexpectedchanges' (selected for archiving automatically by the delete rules analysis) but also the target 'Expected Changes' (must be added manually) should be archived.

Delete Rules and Archiving Actions

When objects are moved from the original database schema to the archive, they are first copied to the archive and then deleted in the original schema. Consequently, parent-child delete rules come into play. Three types of delete rules exist:

• Restrict: It is not possible to delete a parent object for which a child object exists. This is the default foreign key constraint rule.
• Cascade: When a parent object is deleted, its child object is deleted with it as long as the child object deletion is not prevented by the existence of its own child bound by a Restrict deletion rule.
• Set null: When a parent object is deleted, the link to its child object is terminated (the reference is set to null) and the child object remains in the database.

For each relation, one of these delete rules should be specified in the database. (If not, the corresponding archiving action in Valuemation receives an 'Error' value and the archive configuration containing the relation cannot be enabled.)

Which delete rule is used for a particular relation determines the default archiving action and possible alternative actions.

Possible 'Delete Rule - Action' combinations

Please note the distinction between actions 'Don't archive' and 'Exclude':

• 'Don't archive' = archive the parent but unlink the child and do not archive the child
• 'Exclude' = Exclude from archiving any parent with at least one un-archived child

Default action for composite relations

Time-related composite relations (see below for an example) in Valuemation have delete rule RESTRICT. According to the table of 'Delete Rule - Action' combinations these relations would receive default action 'Exclude'. As this would unjustifiably prevent most parent objects of such relations from archiving, a different default action is used for composite relations - 'Archive'. In the 'Relations' list, the fact that a non-standard action has been assigned is signified by a warning in the 'Validation Message' field.

Example:

Archiving configuration with System 'root' object type contains composite relation 'compsystems':
System [1..1] compsystems <--- system [0..*] Compsystem (time-related 1-N link)

• Delete rule: ON DELETE RESTRICT
• Action: Archive
• Validation Message: WARNING - setting action Archive for composite relation although the delete rule is ON DELETE RESTRICT

Note that this 'anomaly' observed with component relations is intentional and the archiving action should be kept at its non-standard default.