Thanks for updating the wiki.
If you try to edit or delete a complex obs via v1/obs you will hit a wall.
Let’s look at the edition for the example. The thread will eventually land in ObsServiceImpl.saveObs(Obs, String) and enter this method handling complex obs: handleExistingObsWithComplexConcept(Obs).
The issue I was facing comes from the initial check being made in it:
if (null != obs.getConcept() && obs.getConcept().isComplex()
&& null != obs.getComplexData().getData()) { ...
If you use v1/obs, the obs’s complex data is never filled up in the thread. And the 3rd check produces a NullPointerException since the complex data is null:
obs.getComplexData().getData()
Hence the need of complexifying the obs before sending it down the thread. By “complexifying” I mean filling up its complex data. However this leads to a further difficulty: in order to obtain the complex obs out of an obs, one must provide a ‘view’. This is the method that does it and invokes the relevant complex obs handler:
public Obs getComplexObs(Integer obsId, String view) { ...
When editing or - worse - deleting a complex obs, it doesn’t make any sense to provide a view to do so. But nevertheless a view must be passed on to move forward. We can get away with it by passing the raw view or something, but that’s not 100% safe in all cases, and shouldn’t be the case by design anyway.