Versioning modes

In order to define a versioning strategy (versioning mode) for an ODABA database, several versioning features are provided. Versioning features may be combined to versioning modes, which defines the way of versioning instances and collections. The following (more or less independent) versioning features may be referred to:

• Versioning scope: The versioning scope defines the scope for consistent versioning

• instance - instance scope
• owner - owner scope
• objectspace - object space scope
• database - database scope
• default - no versioning scope

• Versioning levels: Versioning levels support managed (hierarchical) or simple versioning

• managed - major and minor versions are supported. Major versions are always consistent.
• default - simple (no hierarchical) versioning (major versions are not available)

• Versioning consistency: Different levels of consistency may be requested

• synchronized - version numbers are synchronized among versioning scopes (temporal order)
• default - Independent, i.e. each versioning scope defines its own version numbers

Boldface terms are enumerators for versioning modes. In order to define a versioning strategy, enumerators of different features my be combined or combined enumerators may be selected instead. Some combinations are not supported. E.g. combining database versioning with synchronized versioning does not make sense, since database versioning is always consistent, i.e. synchronized by default. In general, it is more save to use combined enumerator values, which define all supported combinations. After versioning mode has been set, consistency level and versioning scope may be changed (less consistent, smaller scope), when scope and/or consistency level had been defined. When updating versioning modes, one or more of the changes listed below may be included:

• managed --> simple (default)

• synchronized --> independent (default)

• database -->objectspace --> owner --> instance

Until version 12, ODABA supported managed versioning mode, only, in order to manage schema versions. managed versioning mode is still supported because of downward compatibility, only, and cannot be changed without copying the database. Instead of managed versioning mode, one should use managedDatabase versioning mode instead.