Next: Edit History
Up: Version Handling and
Previous: Version Handling and
An object has a history structure node which allows access to previous versions
of that object. Currently, the history structure node contains
the temporal history of the object. The temporal history is
a partial order over the versions representing the relation
`is created before'. When two versions of an object are not related to each
other with respect to this relation, we call them parallel versions.
Versions have a status. When a version is created in a workspace, but
not yet stored in the database, we say that the version is
transient .
When the version has been stored in the database, the version is promoted
to be a working version .
A working version cannot be changed, i.e. when we try to modify a working
version, a new transient version is automatically created.
The history structure node contains the following links for handling
the temporal history.
- VSNET: the VSNET group contains fields which represent
the temporal history involving the working versions.
A field in this group has the form
datetag lbl1 ... lbln where n
1.
The datetag is a unique identifier. The labels represent the
temporal history. In datetag lbl1 lbl2 lbl3 for
example the field asserts that
both 'lbl1' and 'lbl2' are before 'lbl3' in the temporal
history.
- TH_TRANSIENT: this group represents the temporal history
involving transient versions. The fields in the group are
similar to the fields in VSNET. When a transient version
is promoted to a working version (by storing in the
database), the field in TH_TRANSIENT
involving this version is moved to VSNET.
It may happen that transient version are not stored in
the database before logout. Then the content of this version
are lost but the entry in TH_TRANSIENT involving this version
still exists. These entries can be removed using
RTL_REMOVETRANSIENTLINKS().
- SYSTEM:Latest: represents the latest versions with respect
to the temporal history. Observe that SYSTEM:Latest can be
different in a workspace and in the database. SYSTEM:Latest
in the database only considers working versions, while
SYSTEM:Latest in a workspace also considers the transient versions
created in that workspace.
- BUFFERNODE: holds the transient version for an object in
the workspace. It has no meaning in the database.
- SYSTEM:Former_Latest: holds the versions which were
latest since the retrieval of the object, but which are
no longer members of SYSTEM:Latest. This field has
meaning only in the workspaces, not in the database.
When a transient version is created (i.e. upon creation of a new
object, or upon modification of an existing object having only
working versions) the following happens:
- TH_TRANSIENT and BUFFERNODE get a new field involving the new
version.
- A unique datetag is created.
- BUFFERNODE gets a field with the datetag as fieldname and the
version as linkitem.
- TH_TRANSIENT gets a field with the datetag as fieldname and
the version as last linkitem.
- The elements in SYSTEM:Latest are put in the new TH_TRANSIENT
field as linkitems, before the new version.
- The elements in SYSTEM:Latest are added to
SYSTEM:Former_Latest.
- SYSTEM:Latest in the database doesn't change. SYSTEM:Latest in
the workspace becomes SYSTEM:Latest in the database minus the
elements of SYSTEM:Former_Latest plus the new version.
When a transient version is promoted to a working version (i.e.
by an explicit store command)
then the following happens:
- The field in TH_TRANSIENT involving this version is moved to
VSNET.
- BUFFERNODE is set to be empty.
- SYSTEM:Latest (in both the database and the workspace) is set
to be SYSTEM:Latest in the database minus the elements of
SYSTEM:
Former_Latest in the workspace plus the new working version.
- SYSTEM:Former_Latest is set to be empty.
Next: Edit History
Up: Version Handling and
Previous: Version Handling and
Martin Sjolin
Thu Jun 15 20:41:59 MET DST 1995