Draft: ArchiveAction
This is related to nomad-FAIR#1610 (closed) and nomad-FAIR#1955.
The goal is that schema authors can add buttons that allow users to call a "normalize" functions.
This is work in progress and i run into the following issue. Our new system commits lists of changes to the raw-file, processes the raw-file to create an archive, and show the results in the UI. This does not work well, if schema authors use "normalize" functions to change properties that the user can also edit. The "normalize" changes will not be committed to the raw-file. Actions on the raw-file that are based on properties values in the archive that are different from the raw-file will cause unpredictable behaviour. This should not be a problem for atomic property values, but will certainly be a problem for repeated sub-sections. Simple scenario:
- raw-file contains a repeated-subsection with 2 sections
- "normalize" function removes the 2 sections, but only in the archive
- user adds a new section
- new section will be added to the raw-file (which still contains the 2 sections)
- new archive will contain 3 section and not 1
That a bit of a catch-22 here. In the old-system we saved the full-archive as the new raw-file and we run into issues with values the user is not supposed to change. Now we only save changes and run into the opposite issue with values that the user can change.
The only plausible solution is to have two kinds of "normalize" functions. One kind that is commited to the raw-file and another kind with changes only in the archive:
- apply changes to raw-file
- run "raw-file" normalize functions
- save archive as raw-file
- run "archive" normalize functions
- save archive
We wanted to add multiple "normalize" functions anyhow, there could be a parameter for this:
@normalize(raw_file=True)
def remove_measurements(self, archive, logger):
self.measurements = []
@normalize()
def create_plot(self, archive, logger):
# ...