search

SSHOC / sshoc-marketplace-backend

Code for the backend
Apache License 2.0
2 stars 0 forks source link

Problems when updating items for continuous ingestion #475

Open KlausIllmayer opened 1 week ago

KlausIllmayer commented 1 week ago

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:

  1. Created a test source as administrator: `POST /api/sources'
  2. Created a tool as System importer (aka ingestion pipeline): POST /api/tools-services using minimal data (label, description, source and sourceItemId)
  3. Approved this tool as administrator: PUT /api/tools-services/{persistent-id} and removing source and sourceItemId (as described in the mentioned disucssion)
  4. Changed the approved tool as administrator: PUT /api/tools-services/{persistent-id} and added a value in accessibleAt which did not appear by ingest pipeline
  5. Update the tool as System importer: PUT /api/tools-services/{persistent-id} and changed the description but still no value in accessibleAt

As 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?

tparkola commented 2 days 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.

KlausIllmayer commented 2 days ago

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?