A clear and concise description of what the bug is.
The importer is partly agnostic to the specs, at least to specific requirements of the specs. When reading data e.g. in DatasetService.import_dataset (where else do we import data?), we allow reading both 1.7 and 1.8 and any future version. This is relevant for the header definition only, as the rest is handled by the data models and DTOs.
But data is exported (Exporter) using the latest version only, also assuming backward and forward compatibility, i.e. datasets in the database are version-independent, but are always written using the latest version.
This is all fine (and redundant) if nothing changes, and we could simplify the SPECS_EUF definition and the source code in that case, but if we eventually have some incompatible changes (changes affecting or not the database?), the current setup is likely to create long-term maintenance problems and/or confusion for the user.
A clear and concise description of what the bug is.
The importer is partly agnostic to the specs, at least to specific requirements of the specs. When reading data e.g. in
DatasetService.import_dataset
(where else do we import data?), we allow reading both 1.7 and 1.8 and any future version. This is relevant for the header definition only, as the rest is handled by the data models and DTOs.But data is exported (
Exporter
) using the latest version only, also assuming backward and forward compatibility, i.e. datasets in the database are version-independent, but are always written using the latest version.This is all fine (and redundant) if nothing changes, and we could simplify the
SPECS_EUF
definition and the source code in that case, but if we eventually have some incompatible changes (changes affecting or not the database?), the current setup is likely to create long-term maintenance problems and/or confusion for the user.