| Getting started |
The following versioning scenario will illustrate how multiple versions of the database can exist simultaneously. The following example will illustrate how two users create independent edit versions, reconciling the changes against a common database version. This example will show how the versions of the database map onto the underlying database states. The following changes will take place:
Let User1 and User2 be two different users.
Let WORKING be the name of a version of the database that User1 and User 2 will modify.
Let EDIT1 and EDIT2 be the name of two versions of the database that contain the modifications made by User1 and User2 respectively.
This is the sequence of database versions that the user sees:
Change 1:
User1 edits the WORKING version, creating a new version EDIT1, and adding objects 100 and 101. User1 finds no conflicts between the changes in EDIT1 and the WORKING version, so EDIT1 becomes the new WORKING version.
Change 2:
User2 edits the WORKING version, creating a new version EDIT2, adding object 103 and changing Object 101.
Change 3:
While User2 is editing the WORKING version in EDIT2, User 1 again edits the WORKING version creating a new EDIT1, adding Object 102, and changing Object 100. User1 finds no conflicts between the WORKING version and the EDIT1 version, so the User1 changes become the new WORKING version.
Change 4:
User 1 again edits the WORKING version creating a new EDIT1, changing object 101, and deleting object 100. User1 finds no conflicts between the WORKING version and the EDIT1 version, so the User1 changes become the new WORKING version.
Change 5:
User2 completes editing in EDIT2. When EDIT2 is reconciled against WORKING, User2 discovers that object 100 and object 101 have been changed in the WORKING version. User2 decides to accept object 101 from the WORKING version, and object 100 from the EDIT2 version. These reconciled changes now become the WORKING version.
This is the underlying database configuration from the state perspective:
State 0
The initial configuration of the database, the WORKING version.
State 1
Created by User1, referenced by version Edit1. User1 adds objects 100 and 101, then reconciles against WORKING (state0). The WORKING version is changed to state 1.
State 2
Created by User2 from the WORKING version (state 1), referenced by version EDIT2. User2 adds object 103, change object 101.
State 3
Created by User1 from the WORKING version (state 1), referenced by version EDIT1. User1 adds object 102, changes object 100, then reconciles against WORKING (state1). The WORKING version is changed to state 3.
State 4
Created by User1 from the WORKING version (state 3), referenced by version EDIT1. User1 changes object 101, delete object 100, then reconciles against WORKING (state3). The WORKING version is changed to state 4.
State 5
Created by User2 from the WORKING version (state 4) while reconciling EDIT2 (state2) against WORKING (state4). User2 will accept object 101 from WORKING (state4), and will keep object 100 from EDIT2 (state2). The WORKING version is changed to state 5.
This sequence is represented in the diagram below. The state dependencies are shown on the left, while the associated tables are shown on the right.
Example using the simple version modeling schema
The different versions available in this database that correspond to states 1 through 5 are shown below. In the figures, the state column is shown for illustration purposes (it is not visible to the user).
Change 1:
Version-State references after Change 1:
|
Version |
State |
|
WORKING |
1 |
WORKING Version after Change 1 (add objects 100 and 101):
|
OID |
State |
Data |
|
100 |
1 |
a |
|
101 |
1 |
b |
Change 2:
Version-State references after Change 2:
|
Version |
State |
|
WORKING |
1 |
|
EDIT2 |
2 |
EDIT2 Version after Change 2 (add object 103; change object 101):
|
OID |
State |
Data |
|
100 |
1 |
A |
|
101 |
2 |
Bb |
|
103 |
2 |
d |
WORKING Version after Change 2 (no change):
|
OID |
State |
Data |
|
100 |
1 |
a |
|
101 |
1 |
b |
Change 3:
Version-State references after Change 3:
|
Version |
State |
|
WORKING |
3 |
|
EDIT2 |
2 |
|
EDIT1 |
3 |
EDIT2 Version after Change 3 (no change):
|
OID |
State |
Data |
|
100 |
1 |
a |
|
101 |
2 |
bb |
|
103 |
2 |
d |
EDIT1 Version after Change 3 (add object 102; change object 100):
|
OID |
State |
Data |
|
100 |
3 |
aa |
|
101 |
1 |
b |
|
102 |
3 |
c |
WORKING Version after Change 3 (add object 102; change object 100):
|
OID |
State |
Data |
|
100 |
3 |
aa |
|
101 |
1 |
b |
|
102 |
3 |
c |
Change 4:
Version-State references after Change 4:
|
Version |
State |
|
WORKING |
4 |
|
EDIT2 |
2 |
|
EDIT1 |
4 |
EDIT2 Version after Change 4 (no change):
|
OID |
State |
Data |
|
100 |
1 |
a |
|
101 |
2 |
bb |
|
103 |
2 |
d |
EDIT1 Version after Change 4 (change object 101; delete object 100):
|
OID |
State |
Data |
|
100 |
4 |
<delete> |
|
101 |
4 |
bbb |
|
102 |
3 |
c |
WORKING Version after Change 4 (change object 101; delete object 100):
|
OID |
State |
Data |
|
100 |
4 |
<delete> |
|
101 |
4 |
bbb |
|
102 |
3 |
c |
Change 5:
Version-State references after Change 5:
|
Version |
State |
|
WORKING |
5 |
|
EDIT2 |
5 |
|
EDIT1 |
4 |
EDIT2 Version after Change 5 (Merge WORKING and EDIT2, accept object 101 from WORKING and object 100 from EDIT2):
|
OID |
State |
Data |
|
100 |
5 |
a |
|
101 |
4 |
bbb |
|
102 |
3 |
c |
|
103 |
2 |
d |
EDIT1 Version after Change 5 (no change):
|
OID |
State |
Data |
|
100 |
4 |
<delete> |
|
101 |
4 |
bbb |
|
102 |
3 |
c |
WORKING Version after Change 5 (Merge WORKING and EDIT2, accept object 101 from WORKING and object 100 from EDIT2):
|
OID |
State |
Data |
|
100 |
5 |
a |
|
101 |
4 |
bbb |
|
102 |
3 |
c |
|
103 |
2 |
d |