Technical principles

Since each object instance may consist of parts or references and relationships to other instances, versioning practically means versioning related database entries. In order to handle this in a simple but proper way, collections of database entries to be versioned synchronously are defined (versioning scopes). Obviously, each database is a versioning scope (consisting of all database entries in the database). ODABA also supports owner scopes as versioning scope. i.e. all database entries owned by a global instance. Nevertheless, there are many other ways of defining versioning scopes as base for versioning strategies (e.g. object spaces, single instances), which are not (yet) supported by ODABA.

As long as no changes apply to a database entry, the database entry version number remains unchanged, i.e. a database entry version interval starts with the previous version number and ends with the current scope version number when creating the next version. This is not necessarily identical with the real time of change and it may also happen, that several changes of database entries are made within the same version interval, which are not recorded as new versions. Thus, the granularity for versioning is determined by the application and depends on practical requirements. A database may contain only one version interval (all time points) but also create new versions for each update on any database entry.

Supporting versions for a database is mainly a consistency problem. In order to keep older versions consistent, the way used in ODABA is creating a new version for a database entry always, when is is going to be updated and the current database version number is higher than the database entry's version number. This guarantees consistency at least, when the versioning scope is the database. But often this is not, what users want.

In order to make versioning as simple as possible and for achieving a well defined level of consistency, ODABA supports databases and owner scopes as versioning scopes. Thus, the smallest unit which may create versions in ODABA is an owner scope.

Database entries within a versioning scope are referring to the same version number, i.e. versions are created for a versioning scope rather than for object instances or collections. Creating a new version for a versioning scope increases the version number for the versioning scope, only. Versioning itself is based on creating "copies on write", i.e. database entries within a versioning scope are copied, when update is requested for database entries where the version number of the database entry is less than the current version number of the versioning scope.

Hence, version numbers for database entries may have gaps (when not being updated within one or more versions). When requesting the database entry state for a version number which has not been explicitly created for a database entry, the database entry version with the next lower version number is used instead. This technology not only saves a lot of space, but also improves performance when accessing older states of a database entry.

Instead of continuous versioning, ODABA supports version intervals. Within a version interval, instance states may change without creating new versions. A version interval will be terminated by creating a new version for a version scope.

When creating versions for database entries, those are stored as linked list with the most up-to-date version on top. Before reading an older version (e.g. version n) of a database entry, x <= n-1 database entry versions have to be read before (x is not the version number, but the number of versions that had been stored for the database entry, which is usually smaller). Since the last version of a database entry is always read as first entry, versioning does no affect database performance much, as long as processing "current" database entries. Accessing "very old" versions may, however, take some time, depending on the number of database entry versions created for a database entry.