Both variants of "consistent versioning" are explained using an application example. The status "Released" (IZQFR) exists in the status profile. An object with children and children's children is created. All nodes have the versioning type "consistent versioning". After creation, the status of all nodes is "In creation" (IZQER). You can see this on the following screen. 

image-20240606-082656.png

The node "B" is released. An attempt is then made to create a version of node B. → This does not work because with consistent versioning only one version of a node may exist under the same object.

image-20240606-082704.pngimage-20240606-082719.pngimage-20240606-082730.png

All nodes except for the head and node A are released. An attempt is made again to version node B. → This does not work, because with consistent versioning only one version of a node may exist under the same object.

image-20240606-082742.pngimage-20240606-082751.pngimage-20240606-082801.png

Node A is released (all nodes except the header have been released). An attempt is made to version node B. → This does not work, because with consistent versioning only one version of a node may exist under the same object.

image-20240606-082811.pngimage-20240606-082821.pngimage-20240606-082830.png

Versioning an object

The header is released. An attempt is made to version node B. → This is possible and a new version of the header is created with variant 1.

image-20240606-082840.pngimage-20240606-082847.pngimage-20240606-082857.png

The main similarities and differences between the two versions of the head can be seen in the following text and figures. The successor version of the head has the same VNR as the previous version. The version number has been incremented by one. The OGUID is the GUID of the new header and the PREVOGUID is the OGUID of the old header. The validity area of the successor version in the form of the VALIDFR has been adjusted to the current time. The validity area of the predecessor version in the form of VALIDTO was set to the current time minus 1 second.

Previous version:

image-20240606-082905.png

Follow-up version:

image-20240606-082914.png

All children of the old object are moved to the new object. Therefore, there is neither a predecessor nor a successor version of the child. It is the same node in both objects. Accordingly, there is no change to the scope, VNR, or version number. The OGUID is the GUID of the new parent node and the PREVOGUID is the OGUID of the old parent node. The node has RELATTYP = O on the old object and the new object. The following figure shows an example of this for a node of the object.

image-20240606-082925.pngimage-20240606-082933.png

The next step is to try to change node B version 1 to modified under node A version 1. → This is not possible because node B version 1 has been moved to ROOT A version 2.

image-20240606-082947.png

An attempt is made to version header A version 1. → This is not possible because there is already a successor version of header A version 1, header A version 2.

image-20240606-083006.pngimage-20240606-083016.png

Node C versioning

In the next step, child C version 1 is versioned under ROOT A version 2. → This is possible. This example has already been described under Variant 2 and Moving nodes. The result is that node A version 1, node B version 1, and node C version 1, are all versioned under ROOT A version 2. All other nodes D version, E version 1, F version 1, G version 1, and H version 1 are moved.

The following figure shows the result:

image-20240606-083026.pngimage-20240606-083033.png

Successor version of node A                                                                  Previous version of A

image-20240606-083042.pngimage-20240606-083053.png

Successor version of node B                                                                  Previous version of B

Successor version of node C                                                                 predecessor version of C

Node C version 2 under header A version 2 is released. Node C version 1 under header version 1 is given the status "Old version" (IZQAL).

After the release, node C version 2 is attempted to be versioned under header A version 2. → This is not possible because a node cannot appear twice in the same object.

Node G versioning

The Node G version 1 is versioned under the ROOT A version 2. → This is possible. This example has already been described under Variant 2 and Moving nodes. The result is that node F version 1 and node G version 1 were versioned. Node H version 1 was moved.

Successor version of node F                                                                 Previous version of F

Successor version of node G                                                                 Previous version of G

The ROOT A version 2 is released and an attempt is made to version node C version 2 under the version 2 header. → This is not possible. As soon as the head is released, an attempt is made to execute variant 1. To do this, all children must also be released, otherwise versioning cannot be performed. As soon as the header A version 2 is released, the header A version 1 is given the status "Old version" (IZQAL).

The next step is to try to version the header A version 2 directly. → This is not possible. Once the head is released, all children must also be released, otherwise versioning is not feasible.

The status of header A version 2 is first changed to modified. A collective release is then carried out.

The object is now completely released. All previous versions of nodes that have been versioned have been given the status "Old version" (IZQAL) under the header A version 1.  The other nodes have been moved and are available under both objects with the status "Released" (IZQFR). All nodes have the relation type = Original (O).

Versioning node H

Next, node H version 1 is versioned under the header A version 2. → This is possible and a new version of the object is created with variant 1. The header is versioned and the remaining nodes are moved to the new version.

Successor version header A                                                   Predecessor version header A

The node H version 1 under the header A version 3 is versioned. → This is possible. Variant 2 is executed. No new version of the header is created, therefore it is unchanged. The parents of node H, node A version 2, node B version 2, and node F version 2, as well as the node itself, are versioned.

Successor version of node A                                                                Previous version of A

Successor version of node B                        Predecessor version of B

Successor version of node F                                                                Previous version of F

Successor version of node H                                                                Previous version of H

A collective release is executed on header A version 3. The nodes D and E were only moved, therefore they exist under header A version 1, header A version 2, and header A version 3 with the status "Released" (IZQFR). All previous versions of the nodes that were versioned and released in the successor object have the status "Old version" (IZQAL). The remaining nodes have the status "Released" (IZQFR).