Resolve TMSS-315
Closes TMSS-315
Merge request reports
Activity
assigned to @schaap
added 6 commits
- 02c64400 - TMSS-315: added action/url for the SAP's dataproducts
- e4961db5 - TMSS-315: minor fixes, added defaults
- 6ba976b1 - TMSS-315: serialize specifications_doc as JSONEditorField
- ad6c5673 - TMSS-315: fix: if blank is true, then having a default makes the API much more forgiving for POSTs
- 3660dffe - TMSS-315: simplified related_name, hence solved todo
- 201422c7 - TMSS-315: minor fixes
Toggle commit list
I've committed some minor fixes and enhancements in the schema etc.
Code looks ok. Nicely structered.
I'm not sure about the following items, please comment:
- Why is the SIP identifier needed in the SAP schema? I think the SIP is a result of the provenance chain. And hence there should be no SIP in the specification. I do understand that you need a thing like an identifier for handling SAP's when creating SIP's. Can't you make a create_SIP_identifier(SAP) function?
- I looks like there is duplicate information stored in the SAP, for example the stations of antenna_set. Are these needed for the specification, of for creating SIP's? Can't you get these items indirectly by following mySIP.dataproducts.input.subtask.specification (something like that)?
- Resolved by Jorrit Schaap
Thanks for the enhancements. Comment reply:
- I did not come up with the solution to store this in the schema, so maybe Jan David is the better person to answer this. With the SIP identifier table from TMSS-324, we should be able to look up identifiers for a particular SAP from there, so to me this indeed seems a little redundant. I assume there is a reason to do so for future use cases?
- Indeed. I asked the same and Jan David commented on Jira that we can remove the extra station list from there. Then we can also merge the feedback and SAP structures for the antennas.
- Last reply by Jorrit Schaap
-
@mol please comment on Joern's comments above.
assigned to @mol
added 1 commit
We can't generate identifiers on the fly each time we need the identifier of a SIP, because of two reasons:
- once we hand them to the LTA, they are not allowed to change, placing very hard restrictions on the generation code and maintainability. That makes it a weak solution: if the generation code even changes behaviour slightly, even to fix bugs, we start referring to other objects than we did before with the same ID. So the SIP ID not something we can regenerate on the fly as much as that it MUST be the same ID we used earlier, regardless of how we computed it. So we MUST store it as we cannot change the past. Be wary of making dynamic of what in the end is not dynamic!
- we need to be able to import from MoM where we will be given identifiers that won't adhere to our generation function.
So we need to be able to track "foreign identifiers" of our objects. There is no way around it. It may be that the SIP identifier needs two fields, actually: a source and the identifier (for the import from mom). I'll take that up in TMSS-324, in which also the function to generate an identifier will be added.
So the SIP identifier needs to be stored for our SAPs. For now, in the JSON seems sufficient. Alternative would be additional tables for SIP identifiers, for SAPs, subtasks, and dataproducts, respectively.
Wrt repeating information: Note that in general, provenance requires more information to be statically stored that other parts of the model. This is because the information cannot depend on future implementations and algorithms. Furthermore, there is a danger of over-normalisation: sharing a source of information where they can really differ. This needs to be checked and considered for any copy of information we're making, of course. But we will see, once we have the beam former mode added, the following will become possible:
- antenna field list of a dataproduct be a subset of the antenna field list of the SAP
- pointing of a dataproduct be different than the pointing of a SAP
mentioned in commit 8e7e02f9
