1. E.Bertino, L.Matino Object-Oriented Database Systems 1 Chapter.4 Version Seoul National University Department of Computer Engineering OOPSLA Lab.

2. OOPSLA Lab 2 Table of Contents 4 Basic Concepts 4 The Orion Model 4 Proposed Models

3. OOPSLA Lab 3 Basic Concepts 4 Design object 4 Version 4 Derivation and History 4 Workspace 4 Configurations 4 Revisions

4. OOPSLA Lab 4 Design Object 4 In database for design application 4 Aggregation of design data as a coherent unit 4 usually a complex object 4 consists of many component objects primitive complex object 4 Design database

5. OOPSLA Lab 5 Version, Derivation, and History 4 Semantically, a snapshot of a design object 4 In OODB engineering 4 different implementations of the same object 4 revisions of an object 4 Derivation 4 a version of a given object is derived from the previous one by modification to the latter 4 History of version 4 an outline of derivations starting with initial version

6. OOPSLA Lab 6 History of Version O[1] O[0] O[2]O[3] Latest Version Created (default version) O[1.1] O[2.1] O[2.2] O[1.1.1] Current Version Alternatives

7. OOPSLA Lab 7 Configuration 4 A link between a version of a complex object and a version of each of its component object 4 Static configuration 4 Dynamic configuration 4 generic reference 4 current version 4 default version

8. OOPSLA Lab 8 Example of Configuration D[0] D[1] D[k] L[0] L[1] L[j] RT[0] RT[1] RT[i] RPS[W] RPS Composed of Derived from Static Configuration

9. OOPSLA Lab 9 Workspace 4 Workspace is named repository which constitutes 4 work area that is shared by users 4 access control unit 4 private workspace 4 public workspace 4 read & append mode by check-in/check-out protocol 4 semi-public workspace 4 an incomplete object combining the work of several designers 4 read & append mode by check-in/check-out protocol.

10. OOPSLA Lab 10 Revision on Version 4 New version of an object can invalidate some of the objects which reference the given object 4 notifying changes 4 propagating changes 4 Problems in change propagation 4 scope of change propagation in history 4 path for change propagation in configuration

11. OOPSLA Lab 11 RT[0] RT[1] RT[2] RT[i] D[0] D[1] D[2] D[k] L[0] L[1] L[2] L[j] RPS1[j] RPS1 RPS[w] RPS Ambiguous Propagation of a Change

12. OOPSLA Lab 12 Ways of Managing Ambiguities 4 Prevent any change propagation if there is a DAG 4 Propagate the change to all the branches 4 the resulting version as alternatives of the root version 4 Propagate the change, interrupting it when ambiguity arises. 4 Provide operational mechanism whereby user can make their intention unambiguous

13. OOPSLA Lab 13 Schema Version 4 Versions can be applied to classes and schema 4 keep track of the objects created under each schema version 4 define rules both for updating and for deleting versions of a class 4 Schema evolution in Chapter 5

14. OOPSLA Lab 14 The ORION Model 4 Types of Version 4 Transient Version 4 Working Version 4 Released Version 4 Generic Object 4 Version Descriptor 4 Notification of Changes 4 Schema Versions

15. OOPSLA Lab 15 Transient Version 4 In the private workspace 4 Only the creator can update or delete it 4 Can be created 4 from scratch 4 by check-out a released version from a public database. 4 Can be derived 4 from another transient version then the source is promoted to a working version 4 from a working version in a private database

16. OOPSLA Lab 16 Working Version 4 In the private workspace 4 Considered to be stable, thus can’t be updated 4 only deletion by the creator 4 Can be derived from transient version by implicit or explicit promoting the latter

17. OOPSLA Lab 17 Released Version 4 In a public database 4 Cannot be updated or deleted 4 Can be created 4 by promoting the working version 4 from the check-in of the working version

18. OOPSLA Lab 18 CHECK-OUT Promotes or CHECK-IN Public Workspace Private Workspace Created from scratch Promotes (implicit or explicit) Release Version Working Version Transient Version Types of Versions in ORION

19. OOPSLA Lab 19 Generic Object 4 Distinction between versionable object and non- versionable object. 4 Generic (= versionable) object is an instance of a versionable class 4 version-counter 4 next-version-number 4 default-version-number 4 default-switch 4 derivation-tree (a tree of version descriptors)

20. OOPSLA Lab 20 An Example of Generic Object OID O[0] O[1] O[2] OID[0] OID[1] OID[2] Version Instances Generic Object default version Generic Reference (Dynamic) Specific Reference (Static) A B

21. OOPSLA Lab 21 Version Descriptor 4 A version descriptor for each version instance O i 4 the version-number of O i 4 the OID of O i 4 a list of the references to version descriptors for all version instances which are derived directly from O i 4 System attributes in each version instance 4 version-number 4 type-of-version 4 OID of its generic object

22. OOPSLA Lab 22 Messages for Creating Versionable Class and its Instances 4 (define-class Classname :versionable TrueOrNil) 4 Create message to a versionable class, then 4 creates a generic object and the first version instance O i 4 O i is a transient version and becomes the root of the derivation hierarchy for the generic object 4 (derive-version VersionedObject) 4 if VersionedObject is a transient version promotes it to a working version makes a copy of it which becomes a new transient version 4 if VersionedObject is a generic object the message is redirected to the default version.

23. OOPSLA Lab 23 Messages Related to Version (1) 4 ( promote VersionedObject ) 4 promote a transient version to a working version 4 no action on a working version 4 ( demote VersionedObject ) 4 demote a working version to a transient version 4 no action on a transient version and a working version from which other versions have been derived 4 ( change-default-version VersionedObject [NewdefaultVersionNumber] ) 4 by default, version number of the most recent version

24. OOPSLA Lab 24 Messages Related to Version (2) 4 ( delete-object [GenericObject | VersionInstance]) 4 in case of a generic object, the whole derivation hierarchy is removed 4 in case that the version instance is the only instance of the generic object, the latter is also removed. 4 in case of a working version from which other versions have been derived, the descriptor of it is not removed 4 message parent-version 4 message child-version 4 message generic-object 4 message default-version

25. OOPSLA Lab 25 Version and Query 4 Version-number can be used in predicate 4 Queries related with version 4 to find all of the version instances of a versionable class 4 to find the user-defined default version 4 to find the most recent version instance 4 Generic object should be accessed in some queries 4 implementation and performance problem 4 unsupported in ORION

26. OOPSLA Lab 26 Notification of Changes 4 Two main approaches 4 immediate notification by messages 4 deferred notification using flags 4 Flag-based change notification in ORION 4 change-notification-timestamp (CN) 4 change-approval-timestamp (CA) 4 set of events which generate a notification of change

27. OOPSLA Lab 27 Concepts related to Notification of Changes 4 Notification sensitive attributes 4 the attributes referencing the changed object 4 Reference consistent object, V 4 if V.CA >= CN of all the referenced objects by V 4  reference inconsistent 4 system keeps CA and CN for all version instances 4 user has the responsibility for making the instance reference-consistent

28. OOPSLA Lab 28 Schema Versions 4 Approaches to modeling schema versions 4 schema versions 4 class versions 4 dynamic views of the schema 4 Not yet implemented, but model identifies 4 operations which can result in new schema versions 4 types with only transient and working version 4 Problems in schema versions 4 keeping track of objects created under a schema version 4 controlling access of applications to those objects

29. OOPSLA Lab 29 Creator Schema Version 4 In a given object O, identifies 4 the schema version(SV) in which O was created 4 the access scope of SV 4 the direct access scope of SV identifies the set of objects created from SV Schema Version Access Scope Direct Access Scope

30. OOPSLA Lab 30 Proposed Models 4 Time-oriented Data Model 4 Dittrich and Lorie 4 Klahold, Schlageter and Wilkes 4 Landis 4 Batory and Kim 4 Ketabachi and Berzins 4 Beech and Mahbod 4 Vines, Vines and King 4 SUN NSE 4 Apollo DSEE

31. OOPSLA Lab 31 Time-oriented data model 4 Data includes additional properties 4 creation time of a certain object 4 time at which an object is replaced by a new instance 4 Operations such as temporal series analysis 4 ex) rate of sales increase as a function of time 4 No consideration of operational aspects such as 4 inheritance, propagation of changes, workspaces, etc

32. OOPSLA Lab 32 Version Model by Dittrich and Lorie 4 Design object 4 set of versions with a specific current version 4 reference other objects  hierarchical aggregation 4 direct reference & generic reference 4 Generic references 4 resolved by environment mechanism which is a link between design objects and their specific versions between design objects and another environment 4 Clusters of logic versions 4 User can further structure versions such as grouping

33. OOPSLA Lab 33 Model by Klahold, Schlageter and Wilkes 4 Version graph 4 similar to the concept of history 4 partitions 4 groups together a set of versions 4 a level of consistencey 4 Views of subsets of a version’s graph

34. OOPSLA Lab 34 Model by Landis 4 Non-linear history 4 consists of several derivation branches 4 the current version and the default branch. 4 Version references 4 supports dynamic configuration 4 Change propagation 4 a new version creation, schema change, value change 4 Additional mechanism to control changes 4 delta sets which are similar to the log 4 pended version creation is similar to checking-in in semi-public workspace

35. OOPSLA Lab 35 Model by Batory and Kim 4 Extension of the E-R model by inheritance 4 Molecular objects 4 to define complex objects 4 all versions are the instances of a molecular object 4 Type-version generalization 4 to model the version history of a molecular object 4 Parameterized versions 4 to use any version of a component object as the a component of a molecular object 4 provide support for the dynamic configuration

36. OOPSLA Lab 36 Model by Ketabachi and Berzins 4 Refinements for different descriptions of a object. 4 template refinement to describe aspects of an object 4 explosion refinement to list the versions of the component objects 4 instance refinement to describe the revisions and alternatives of a given object 4 Incremental refinements 4 to describe the evolution of an object 4 Graphs to represent the history of a version 4 refinement graph to derivation relationship 4 IRG(incremental refinement graph) to stores differences between a version and the father version.

37. OOPSLA Lab 37 Model by Beech and Mahbod 4 IRIS project 4 Version instances are organized into version sets 4 associated to a single generic instance 4 Version graph 4 functions - first, last, next version, preceding version 4 Messages to create new versions 4 mutation or propagation 4 References can be generic or specific 4 generic references are resolved by contexts mechanism which consists of a trigger and a user-defined rule

38. OOPSLA Lab 38 Model by Vines, Vines and King 4 Change control and versions model of GAIA 4 Versions are identified with timestamps 4 Version is related to the event which generated it 4 version sensitive relations 4 change sensitive relations 4 Specific objects for managing changes 4 change request object 4 change notification object 4 configuration object

39. OOPSLA Lab 39 SUN NSU Model 4 System for software development environment 4 Types of object 4 FILE, TARGET, COMPONENT, LINKDB 4 Versions are stored in the form of interleaved deltas inside an object 4 Access paradigm is based on 4 acquire, modify and reconcile operations 4 Change notification support

40. OOPSLA Lab 40 Apollo DSEE Model 4 System for software development environment 4 Components 4 history manager - reserve and replace operation 4 configuration manager to define module composition configuration thread and bound configuration thread(BCT) 4 task manager 4 monitor manager 4 advice manager 4 Versions of program modules are stored by using interleaved deltas 4 Release = a software system + BCT + a keyword.