Closed jh-RLI closed 2 years ago
I agree, that there are two ways forward here:
structure.py
) and create a second that reflects the newer version and implement translations between those representations.I think I would prefer the first one, given our use-cases. The intention of OMI is that users can use the present python structures in their code to define metadata objects. If these structures change, it may break the code of these users. But I do not have any definite opinions on this.
@MGlauer I have started to implement this towards the approach described in 1. In the process more questions came up: (have not yet pushed anything)
[1]
[2] old
class JSONCompiler(Compiler):
__METADATA_VERSION = "OEP-1.4.0"
.....
new
class JSONCompilerOEMv1_4_0(Compiler):
__METADATA_VERSION = "OEP-1.4.0"
....
class JSONCompilerOEMv1_4_1(Compiler):
__METADATA_VERSION = "OEP-1.4.1"
.....
class JSONCompilerOEMv1_5_0(Compiler):
__METADATA_VERSION = "OEP-1.5.0"
.....
class JSONCompilerOEMv1_5_1(Compiler):
__METADATA_VERSION = "OEP-1.5.1"
.....
When updating the structure.py with the latest metadata version (oem v1.5.0 and v1.5.1) I noticed that older versions are no longer supported when the structure is changed. For example in OEM v 1.5.0 the key temporal has been changed. Here the subkey timeseries is now a separate object.
Old until oem v1.4:
New in oem v1.5:
Is there a way to keep the structure.py downward compatible without keeping a class for obsolete structure. Or would one structure.py have to be created for each OEM version.
@MGlauer as you implemented this could you help me out with this? Let me know if you understand my issue description.