Database Management
Reference Manual
Introduction to Database Concepts
:
Extracts
: Merge Algorithm
Merge Algorithm
On issue or flush, changes made in an extract will be merged back to the parent extract.
The basic approach is that any changes made to the extract are applied to the parent extract, as shown below:
The granularity of this merge is at the attribute level, i.e. two users can change different attributes on the same element and merge their changes together. If they modify the same attribute then a 'last back win' strategy is used.
AVEVA E3D™ makes sure that all merges are valid at the raw database level, i.e. the data will be DICE (Database Integrity Checker) clean. However it is not possible to make sure that the data is consistent in engineering terms. Thus it is highly recommended that when variant data is flushed back, Datacon checks and Clasher checks are run on the resulting version.
The definition of the different sessions for issue and flush are:
Base Session
Session on parent when Refresh was last done
From Session
From session on child extract
To Session
New session on parent
The definition of the different sessions for refresh are:
Base Session
Session on parent when Refresh was last done
From Session
From session on child extract
To Session
New session on parent
The definition of the different sessions for drop are:
Base Session
Session on parent when Refresh was last done
From Session
From session on child extract
To Session
New session on child
Note:
The standard flush and issue commands also do a refresh. This makes sure that there is a suitable base session for the next extract operation.
The drop command compares the elements that are NOT to be dropped and applies the changes to create a new session.
The same algorithm is used for SAVEWORK and GETWORK.
There are two exceptions to the merge criteria as follows:
1.
Once an element is deleted, then it stays deleted regardless of any conflicts in merging. For example, user 1 deletes /BOX, whereas user 2 changes an attribute of /BOX. If user 1 issues his change before user 2, then user 2's change will have no affect.
2.
If the element type is changed, then the merge is done at the element level rather than the attribute level, i.e. all the current attribute values are taken regardless of whether they have changed. Any attribute changes made by other users will thus be lost.
1974 to current year.
AVEVA Solutions Limited and its subsidiaries. All rights reserved.
