Dataset management#
This article serves as an internal guideline on how we intend to manage the addition, reprocessing and, if needed, removal of datasets.
We keep a list of actively maintained datasets in datarecords.datasets.
This list represents a desired state.
We use workflow automation to automatically produce and remove datasets in our public store, should the desired state deviate from the actual state.
Thus, we only update the desired state manually and the system will adjust automatically.
Managing datasets#
A DSCollection is essentially a dataset in multiple versions. Within a DSCollection, instances is a list of DS objects which describe the individual datasets (dataset versions) themselves.
For all DSCollections, there should exist one and only one default to which we point end users.
DS instances, once created, stay as they are, except:
Changing a dataset from ever-growing in time to fixed in time is acceptable because nothing about the processing, object ID, or metadata changes.
- DS(end=None)
+ DS(end=datetime)
Switching
forevertoTruemeans that the dataset should never be deleted.
- DS(forever=False)
+ DS(forever=True)
defaultdatasets can be switched if and only if the property of onedefaultperDSCollectionis maintained.
- instances=[DS(rev_or_branch="old", ..., default=True), DS(rev_or_branch="new", ..., default=False)]
+ instances=[DS(rev_or_branch="old", ..., default=False), DS(rev_or_branch="new", ..., default=True)]
Switching the default from one to another DS should only be done once the new dataset has caught up processing, i.e. first add a new DS, then let the processing catch up, then switch the default.
Otherwise, users would immediately be directed to a broken dataset.
Deleting datasets#
The following framework describes when and how to delete datasets.
If an error is discovered in a code revision used to process the data, and if
forever=False, we can delete the dataset. Ifdefault=True, delete the dataset if and only if there exists another dataset spanning the entire temporal extent of the dataset in question which should be the newdefault. Switch todefault=Truefor that dataset.The same policy governs deleting a dataset in case of improved processing. However, if no errors exist in a legacy dataset for which processing has been altered and improved, keep the dataset unless storage is an issue.
Errors with dynamic code revisions
In the case of (1), if the dataset in question is processed with incrementally updating code, the following steps should be taken to ensure safe deletion and continued development:
fix the error on the branch used to process the data
add a new instance of
DS(rev_or_branch="branch_in_question", ..., build=old_build+1)wait until re-processing for
DS(build=old_build+1)has caught up to that ofDS(build=old_build)remove
DS(build=old_build)