Extra information about partial updates in responses

[fgalan]

(Comes from PR #3498)

NGSIv2 doesn't provide information about partial updates. For instance, if I do an update with attribute A and B, but B doesn't exist in the entity, A is updated and response is like this:

{"error":"NotFound", "description":"The entity does not have such an attribute"}

More information could be provided. Two alternatives:

1. Use the "description" string for that (in a similar way "PartialUpdates" does, in NGSIv2-client forwarding scenarios). This way is compliant with NGSIv2 (as description is for humands and may vary between implementations).
2. Use new fields in the JSON. This way is not compliant with NGSIv2 (as new fields cannot be introduced in error responses) but it could be part of the next review (NGSI v2.1) in a backward compatible mode (new fields doesn't hurt to old implementations).

This information could be used to provide better responses in "PartialUpdate" messages in CPr-NGSIv2 forwarding scenarios (see #3498 for more details) but only in the second case (as in the first one, as we say, description is not formal and may vary between implementations).

[fgalan]

Upon completion of this issue maybe the following fragment in context_providers.md needs to be adjusted:

In the case of partial updates (e.g. POST /v2/op/update resulting in some entities/attributes being updated and other entities/attributes not being updated due to failing or missing CPrs), a 404 Not Found is returned to the client. The error field in this case is PartialUpdate. The description field contains a list of attributes corresponding to the partial update. In the case of NGSIv1 CPr, the CPr response to CB returns exactly the attributes that weren't updated in a partial update. In the case of NGSIv2 CPr, the CPr response to Orion doesn't provide information about which attributes were updated and which ones were not in a partial update. Thus, in a general case the list of attributes in description contains at least one attribute that was not updated (to a maximum of all them). If only NGSIv1 CPrs are involved in the fowarding, the list precisely identifies only the attributes that weren't updated.

[jmcanterafonseca]

NGSI-LD has already solved this issue

https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.01.01_60/gs_CIM009v010101p.pdf

Section 6.6 207 Status

UpdateResult data structure (Section 5.2.18)

[Anjali-NEC]

Hi @fgalan Sir,

As per my understanding this issue is fixed. Please close this issue.

[fgalan]

As per my understanding this issue is fixed. Please close this issue.

I'm not sure about it...

Could you elaborate on it? Why do you say it is fixed? Or, even better, describe the test case that show it.

Thanks in advance!

[Anjali-NEC]

I'm not sure about it...

Could you elaborate on it? Why do you say it is fixed? Or, even better, describe the test case that show it.

Thanks in advance!

Yes you are correct this issue is not fix yet. I would like to work on this please assign this issue to me.
As per my understanding we need to add the "description" string for that in a similar way "PartialUpdates" does In case of attribute doesn't exist in the entity.
For example : Update entity E1 with attribute A and B, but B doesn't exist in the entity, A is updated and response is like this:

{"error":"NotFound", "description":"The entity does not have such an attribute : { E1-T1 : [B] }"}

[fgalan]

I'm not sure about it...
Could you elaborate on it? Why do you say it is fixed? Or, even better, describe the test case that show it.
Thanks in advance!

Yes you are correct this issue is not fix yet. I would like to work on this please assign this issue to me. As per my understanding we need to add the "description" string for that in a similar way "PartialUpdates" does In case of attribute doesn't exist in the entity. For example : Update entity E1 with attribute A and B, but B doesn't exist in the entity, A is updated and response is like this:

{"error":"NotFound", "description":"The entity does not have such an attribute : { E1-T1 : [B] }"}

Thanks for your willingness to work on this issue! You have been assigned

I think your understanding is correct, although I could provide more precise feedback when first version of the PR with the implementation comes.

[Anjali-NEC]

Hi @fgalan Sir,

I have fixed this issue in PR #4097 Please review my PR and if it is ok then please merge it into master. Thanks

[fgalan]

Fixed in PR #4447. Have a look to orion-api.md modifications in that PR to know how finally this works, per request.

The implemented solution tries to minimize backward compatibility issues. For a more ambitious (but aggressive from the point of view of backward compatibility) this issue has been created as a kind of follow up: #4452