CdmVersioning » History » Version 14
Markus Döring, 02/28/2008 01:51 PM
1 | 1 | Markus Döring | {{>toc}} |
---|---|---|---|
2 | |||
3 | |||
4 | |||
5 | |||
6 | # CDM Versioning |
||
7 | |||
8 | 3 | Markus Döring | The [[CdmLibrary]] is supposed to support versioning of CDM data. The simplest approach to create a new version would be to copy every _current_ object in the CDM and leave the old ones untouched. This would effectively mean a copy of the entire database for every single version, because nearly all objects in the CDM are related to each other in some ways. Obviously this is not a scalable solution. We will have to address versioning therefore on the atomic domain objects. The following graphic shows the complexity and dependencies of a single change to a Person in the CDM: |
9 | 1 | Markus Döring | |
10 | |||
11 | 2 | Markus Döring | ![](version_complex_objects.png) |
12 | 1 | Markus Döring | |
13 | |||
14 | 4 | Markus Döring | ## Version In Time. A View |
15 | 1 | Markus Döring | |
16 | 12 | Markus Döring | For a single point in time a consistent complex object can be assembled based on the multiple versions stored. We refer to it as a _view_ into historic versions. |
17 | 4 | Markus Döring | |
18 | |||
19 | 13 | Markus Döring | The following example shows a change to a name object which is part of a taxon and itself has a reference and author object attached. Note that the same author object is used by the name and by the reference object (the name in fact _caches_ the author object which in a fully normalised system should only be attached to the nomenclatural reference): |
20 | 1 | Markus Döring | |
21 | 12 | Markus Döring | ![](name_change.png) |
22 | 1 | Markus Döring | |
23 | 14 | Markus Döring | The system therefore can extract 2 views on the complex taxon object. One with the old name and one that includes the new version of it: |
24 | 12 | Markus Döring | |
25 | 14 | Markus Döring | [!taxon_versionspng!|!taxon2_versions.png!] |
26 | 12 | Markus Döring | |
27 | |||
28 | ---- |
||
29 | |||
30 | ![](version_unidirect.png) |
||
31 | |||
32 | ---- |
||
33 | |||
34 | ![](version_bidirect.png) |
||
35 | 4 | Markus Döring | |
36 | |||
37 | ## Versioning = Denormalisation? |
||
38 | |||
39 | A new version of an object will not automatically be applied to all other previously related objects. A modified name will therefore not be applied to all taxa using that name without manual interaction, i.e. agreement from the user that owns the other taxon. |
||
40 | |||
41 | |||
42 | Versioning and this non-automatic propagation of updated objects therefore leads to very similar effects as denormalisation. With the exception that there is a clear link between the versions so an automatic update _could_ be done at any time. |
||
43 | |||
44 | |||
45 | |||
46 | ## Accessing versions. DAO Implementations |
||
47 | |||
48 | It would be elegant to implement versioning entirely outside of the domain model, only in the Data Access Objects (DAOs). |
||
49 | |||
50 | |||
51 | Access to the latest version should be the default and as fast as possible. |
||
52 | |||
53 | |||
54 | Historic versions can and maybe even should be read-only. |
||
55 | |||
56 | |||
57 | Domain class methods like _getTaxonName()_ should not need to know (i.e. have a parameter) which view they are working on. If a taxon has different name versions in time, how does the taxon object know which to return? The method would have to accept a view parameter or store the view in the taxon object. But as the identical, persistent taxon object is used for several views, it cannot be stored in the persistent taxon object. |
||
58 | |||
59 | |||
60 | 5 | Markus Döring | It therefore seems best to create transient copies of historic versions and only allow the current view to be persistent, i.e updateable. The assembling of such _transient deep copies_ would have to be done in the DAO layer. As those copies are transient, the complex object boundaries have to be defined as part of the DAO method too, as no further lazy loading will be possible. Domain method calls to related objects which were not immediately loaded will get NULL! |
61 | 4 | Markus Döring | |
62 | |||
63 | |||
64 | |||
65 | ## Changes To Datamodel |
||
66 | |||
67 | |||
68 | ### Many-Many Relations |
||
69 | |||
70 | 9 | Markus Döring | This solution modifies the referencing side of a domain model and keeps a list of all versions for a certain property. That means converting all properties to lists or adding an additional list property for each existing property. For example consider the name property of the Cdm:taxon:TaxonBase class: |
71 | 4 | Markus Döring | |
72 | 7 | Markus Döring | ~~~ |
73 | 8 | Markus Döring | class TaxonBase extends VersionableEntity |
74 | TaxonNameBase name; |
||
75 | Set<TaxonNameBase> nameVersions = new HashSet<TaxonNameBase>();; |
||
76 | 7 | Markus Döring | ~~~ |
77 | 4 | Markus Döring | |
78 | It allows for relatively fast database access to a complex object view. |
||
79 | |||
80 | |||
81 | It means a lot of extra coding, as all properties have to be duplicated and probably regular setter/getter methods have to be adapted. |
||
82 | |||
83 | |||
84 | |||
85 | ### Linked Lists |
||
86 | |||
87 | 8 | Markus Döring | See Cdm:common:VersionableEntity previous and later property. Needs generic classes. |
88 | 4 | Markus Döring | |
89 | 7 | Markus Döring | ~~~ |
90 | class VersionableEntity<T extends VersionableEntity> |
||
91 | 8 | Markus Döring | T nextVersion; |
92 | T previousVersion; |
||
93 | 7 | Markus Döring | ~~~ |
94 | |||
95 | |||
96 | 1 | Markus Döring | ### Version Array |
97 | 5 | Markus Döring | |
98 | 8 | Markus Döring | Cdm:common:VersionableEntity could have a version array property in addition to a pointer to the latest version. Needs generic classes. |
99 | 1 | Markus Döring | |
100 | ~~~ |
||
101 | class VersionableEntity<T extends VersionableEntity> |
||
102 | T currentVersion; |
||
103 | List<T> allVersions = new ArrayList<T>(); |
||
104 | ~~~ |
||
105 | 8 | Markus Döring | |
106 | |||
107 | 11 | Markus Döring | ## Bidirectional CDM Relations |
108 | |||
109 | Versioning bidirectional relations could cause problems as a change to any side will change the object n both sides, propagating a change. |
||
110 | |||
111 | |||
112 | |||
113 | 8 | Markus Döring | ## Creating New Versions |
114 | |||
115 | Does a new version become a new object (in Hibernate sense) or does the old version become a new object? |
||
116 | |||
117 | |||
118 | Creating new current versions are bad for desktop applications like the [[TaxonomicEditor]], as they need to destroy all their objects, use the new ones and reregister listeners and other GUI components. |
||
119 | |||
120 | |||
121 | Creating a new old version means updating a lot of _unchanged_, existing objects as they now point to different object than before. |
||
122 | |||
123 | 5 | Markus Döring | |
124 | |||
125 | ## Unversioned CDM Classes |
||
126 | |||
127 | 6 | Markus Döring | Parts of the [[CommonDataModel]] would not need to be versioned. This probably applies to Cdm:common:DefinedTermBase and all relationship classes that currently do not inherit from a common superclass (but probalby should). |