Currently database models are too different. A few changes are needed, roughly as follows:
- Add a free JSON field to TimeSeries for miscellaneous time series processes
- Rename Transect to CrossSection
- Split CameraConfig into CameraConfig (containing only the pose information) and VideoConfig (combining camera_config, recipe, cross_section and cross_section_wl with relationships)
Then in the API end points, POST PATCH and GET requests should be modified so that they are also compliant with these models and VideoConfig related end points must be entirely added as these are now non-existent.
The admin front end should also be extended.
- The current CameraConfig should be simplified: fields for selection of recipe and cross section must be removed
- An admin view must be added for full VideoConfigs which allows for combining a recipe, one or two cross-sections and a CameraConfig into a VideoConfig, the same way as ORC-OS does it.
A database migration is needed that for existing CameraConfig objects, creates a VideoConfig object that has an identical primary key as the old CameraConfig used to have. The old camera config in turn must keep its original pk so that migrations on the ORC-OS side do not require changing of the remote_ids.
Currently database models are too different. A few changes are needed, roughly as follows:
Then in the API end points, POST PATCH and GET requests should be modified so that they are also compliant with these models and VideoConfig related end points must be entirely added as these are now non-existent.
The admin front end should also be extended.
A database migration is needed that for existing CameraConfig objects, creates a VideoConfig object that has an identical primary key as the old CameraConfig used to have. The old camera config in turn must keep its original pk so that migrations on the ORC-OS side do not require changing of the remote_ids.