Open squaregoldfish opened 5 years ago
An alternative (probably addition) is to add the project info to the export manifest.
Maybe better than a bit mask will be a database table of known projects with a 1:∞ link table to the instruments.
This can also be used to track failed uploads. Each data set can have an upload status variable, with a status for each project it's attached to.
For the API, Maren currently uses these calls:
Base new API calls on this workflow.
Also add into the project definitions which export format should be used. This can then be used to configure Nuka for the versions with non-salinity flags, and Maren's script won't need any special logic.
Possible database structures:
If we store exports, do we want to store the PIDs/DOIs?
Higher priority tasks have put this on hold.
The export scripts will have to become more intelligent, knowing which projects a dataset has been exported for, and which not.
When an instrument is set up, we can define which projects its data should go to (ICOS, SOCAT, CMEMS etc). Then exporter scripts can interrogate that to find out which data sets to extract.
A bit mask is probably the best data structure.
We may need multiple bit masks for different stages (e.g. some projects may only want final data, some might only need NRT, etc)