Rothamsted-Ecoinformatics / farm_rothamsted

Custom farmOS features for Rothamsted Research.
GNU General Public License v2.0
5 stars 1 forks source link

Experiment module: Link geometry and variable upload files to revision history #645

Open paul121 opened 3 months ago

paul121 commented 3 months ago

Right now it is not easy to determine the "first upload" of column, plot variable and geojson data. These fields are dumped the plan.file field and have data parsed out into JSON fields on the Plan and Plot entities, but they are separate.

Being able to determine the "first upload" would benefit us in a few ways: https://github.com/Rothamsted-Ecoinformatics/farm_rothamsted/issues/632#issuecomment-2043154398

I would like to create dedicated file fields on the plan for column + column_level + plot_attribute CSVs + plot geojson. This would allow us to look in a single place to see if this data has been uploaded in a "first upload". It would also make it easier to determine what the "current set" of data files are for the plan, rather than parsing through a longer list of files that have been uploaded and attached to the plan.

aislinnpearson commented 3 months ago

@mstenta, @paul121 and I had an interesting conversation about this issue. We realised that it overlaps with a previous conversation we had were FarmOS is increasingly becoming the source of truth at Rothamsted, and so if more than one version of a file is updated, it can be confusing as to which is the 'correct' or current version. At the time we suggested simply not keeping a copy of those files, but instead creating an 'export' button that would allow you to download the three .csv files and an annotated geoJSON (which also links to this issue here about Frictionless data exports #522).

However in today's call we agreed this is not ideal: better to keep a copy of the file just in case. @paul121 came up with what is the ideal solution then that if you replace these named files (as per his comment above) they would exist only with that revision. In this way you keep a copy of all the files, clearly associated with the current revision. I think that is a nice solution to implement asap.

In terms of the longer term/ bigger picture we talked about how files are handled more generally and I have created a separate issue for that here: