Detecting Conflicts

Conflict detection is based on the existing UpdateViewer change detection code. This code collects changes to the user view for each account assigned to the user. It also detects changes to a set of hardcoded attributes in the waveset view and also to extended attributes. The list of hardcoded updatable waveset attributes includes:

Constants.ACCOUNT_ID
Constants.PASSWORD
Constants.EMAIL
"disabled"
"locked"
"lockExpiry"
"questionLocked"
"questionLockExpiry"
"correlationKey"
"passwordExpiry"
"passwordExpiryWarning"
"organization"
"roleInfos"
"applications"
"resources"
"resourceAssignments"
"exclusions"
"assignedLhPolicy"
"adminRoles"
"capabilities"
"controlledOrganizations"
"userForm"
"viewUserForm"
"customForm"
"forwardingApprover"
"questions"
"suppliedQuestions"
"idmManager"
"delegates"

In the Administrator interface, such changes to these User view attributes are detected by the existing UpdateViewer and presented to the administrator for confirmation when the Save button is pressed. It appears as a list of attribute names with corresponding old and new values.

Conflict detection for optimistic checkout is based on the UpdateViewer update view and proceeds as follows:

1. The list of local changes is fetched from the view. The UpdateViewer has already calculated this change list, and it is present in the User view.

2. The list of remote changes is computed by fetching the baseline view stored in the view at checkout time. These changes are compared to a fresh view based on the current repository User object in the same manner as the local changes are computed. A similar change list is produced.

3. If a changed attribute appears in either the local or remote changes but not both, then no conflict is indicated.

4. If a changed attribute appears in both the local and remote changes and has the same new value in both, then no conflict is indicated. This comparison is straightforward for attributes whose values are not lists. However, attributes that contain lists are processed differently, depending on the type of list.

The following types of lists need to be considered when checking for conflicts:

• Non-Named GenericObject Lists

• Lists of Named GenericObject Elements

Non-Named GenericObject Lists

Lists composed of elements which are not named GenericObjects never produce a conflict. Since element-level list conflict detection is predicated on the ability to identify list elements (by name) and no such name exists in this case, no conflicts can occur - list order is not significant. As such, for such lists, conflict detection is bypassed. Merging, however, still occurs at the element level.

For example, consider an attribute whose value is a list of strings and whose initial value is [“A”, “B”, “C”]. Then two edits (such as two UserView checkout() methods) occur with this as the starting state for this attribute value. The first edit removes element B, resulting in a final list value of [“A”, “C”] and commits that change. The second edit (an optimistic edit) starts with the same initial value of the list ([“A”, “B”, “C”] but then removes element “A” and adds element “D” giving a local end result attribute value of [“B”, “C”, “D”]. The final merged list value is [“C”, “D”] because:

• The first edit removed “B”.

• The second edit removed “A”.

• The second edit added “D”.

Lists of Named GenericObject Elements

Assuming named GenericObjects with the same name represent the same object allows for better and more granular conflict detection. Changes in a named element are identifiable since list elements with the same name are assumed to be the same object. In this case, a failing equality comparison indicates a conflict. List additions and deletions are also similarly discernible.

For lists of named GenericObjects, Waveset can detect whether an element has been added, deleted or modified in both the local and remote changes. The system then compares the resulting two lists to determine if a conflict is indicated using the following rules:

Table 11–1 Local and Remote Conflict Checks

	Local Add	Local Delete	Local Change
Remote Add	Add conflict is not equal
Remote Delete		No	Yes
Remote Change		Yes	Conflict if not equal

The blank cells in the table indicate that such a case is not possible. Since the baseline view is the same for computing both local and remote changes, a list addition in one set of changes indicates that the value was not present in the baseline. Therefore, it is not possible to delete or change this (non-existent) element value in the local or remote changes. Similarly, the deletion of an element or change to an element value indicates that the value was present, and an addition of that value is not possible.

An example of such a list that contains named GenericObject elements is the roleinfos attribute. Both the old and new values are lists of objects which are named by the role name. An addition or deletion of such a named element can be determined by querying the list by object name. For cases where the named element is present in the list in both the local and remote changes, the (Generic) objects can be compared for equality. If the new values are identical (equal), then this is not considered a conflict.