Open KlausIllmayer opened 1 week ago
Can you check what is the payload for in the last PUT call (5.)? From what I see - if there is no information on the accessibleAt in this request's payload then the tool is updated to have no such values. This is most probably why you get what you described.
That is true, in the PUT from step 5 there is no accessibleAt present. Seems that I was a little bit unclear with my description. The expectation is, that if an update by the ingest process (= step 5) happens, that the changes that were done in the marketplace (= step 4) stay, as they were done after the last ingest (= step 2). Otherwise, we would lose the curated information from the marketplace users, which would be a bad thing. And in the linked issue I understand the comment of Michał that the different versions are handled and merged (he speaks about three versions: the last ingested, the change in marketplace and the current ingested version). We don't like to intervene at the source of the ingest (and in most cases we can't) that they add additional information. Instead we expect, that the changes of the marketplace are handled at least on the same level as the changes at the source. @tparkola I hope, it makes clearer what is expected?
This is based upon the old discussion at https://gitlab.gwdg.de/sshoc/sshoc-marketplace-backend/-/issues/85#note_536637
Scenario: for continuous ingestion we like to call the PUT call and it should merge as explained in the above mentioned discussion
Problem: I'm not able to get to the expected behavior in the case when there is a change of the item on SSHOMP in between - this change gets lost but in my understanding it should be merged
Steps to reproduce:
POST /api/tools-services
using minimal data (label, description, source and sourceItemId)PUT /api/tools-services/{persistent-id}
and removing source and sourceItemId (as described in the mentioned disucssion)PUT /api/tools-services/{persistent-id}
and added a value in accessibleAt which did not appear by ingest pipelinePUT /api/tools-services/{persistent-id}
and changed the description but still no value in accessibleAtAs a result of step 5 I would expect that for the new ingested version of the tool the description is changed (based on the change of the System importer) and that the accessibleAt value stays (based on the change on the SSHOMP by the administrator). But when looking on the return values the accessibleAt value is not there.
@tparkola is there a chance that you look into this behavior and into the mentioned old discussion so that you may able to tell me if I'm doing something wrong or if my expectation is wonrg or if there is a bug in the described update mechanism?