Attribute update without losing existing metadata

[fgalan]

Is your feature request related to a problem / use case? Please describe.

Some metadata are "sticky" to the attribute. For instance, a metadata meaning the units/format of the attribute value or the proposed extraLoc metadata in issue #4032

However, the current semantics for attribute update is that the metadata is part of the value. So, if we have attribute temperature with value 42 and metadata unit with value "Celsius" and we do:

PUT /v2/entities/E/attrs/temperature
{
  "value": 45,
  "type": "Number"
}

Then the unit metadata will be deleted. The only way of avoiding the removal is:

PUT /v2/entities/E/attrs/temperature
{
  "value": 45,
  "type": "Number",
  "metadata": {
    "unit": {
      "value": "Celsius",
      "type": "Text"
    }
  }
}

Describe the solution you'd like

CB should implement to two different behaviours for attribute updates:

1. The metadata of the attribute after the update will be the metadata included in the attribute update request, replacing the previous metadata (this is the current behaviour)
2. Only the metadata in the attribute update request are added/modified

There are two alternative implementations:

• A. Default behaviour is 1 and a new options will change behaviour to 2. Fully backward compatible
• B. Default behaviour is 2 and a new options will change behaviour to 1. Not backward compatible but maybe better from a operative point of view

We have to choose one of these when we address this issue.

Describe alternatives you've considered
Not aplicable

Describe why you need this feature

• To approach a new use case.
• To improve or simplify an scenario.

Do you have the intention to implement the solution

• Yes, I have the knowledge to implement this new feature.

[mrutid]

B option is the desired behavior from my point of view

[fgalan]

At the end the name of the option will be: overrideMetadata

[fgalan]

Fixed by PR #4033

[tstorek]

@fgalan thanks, for all the work that you put into this piece of software. However, it would be very kind if you would highlight such change as a BREAKING CHANGE in the semantic release. As this is a breaking change it should have been a major release, right? Especially important if a feature is not part of the specifications ;)

It took me quite a while to figure this out but it actually occurred with version 3.7.0.

So something was a little messed up with this.

Thank you anyway.

[fgalan]

Sorry heard that...

However, note that in the (rare) cases in which a Orion release breaks the backward compatibility, it is properly warned in the release notes. For instance:

• In https://github.com/telefonicaid/fiware-orion/releases/tag/3.6.0 there is a note about the change in default metadata update semantics (well, we use NOTE instead of BREAKING CHANGE, but it's the same)
• In https://github.com/telefonicaid/fiware-orion/releases/tag/3.1.0 there is a note about deprecation of initial notifications
• In https://github.com/telefonicaid/fiware-orion/releases/tag/2.2.0 there is a note about the the removal of metadata id specific semantics
• ...and so on

Bottom line: it is important to read the release notes before to upgrade to a new version :)

[tstorek]

@fgalan I saw it, but it was somehow confusing that the NOTE is in version 3.6.0 but the error occurred later in 3.7.0.

I would just recommend highlighting BREAKING CHANGES and making them more prominent.
Ideally, in the version number ;)
From a minor release, I usually expect new features and maybe some bug fixes (patch-release).

In this case, it was not as critical, as it rather protects existing data, but it prevented updating behavior.
Hence, some functions did not work as expected. I am just saying that because if further services rely on the reference implementation might result in unsuspected behavior elsewhere.

The FIWARE community had such a hard time convincing people in so many application domains.
Therefore, breaking changes are always a hassle.

Nevertheless, I like the feature ;)

[fgalan]

@fgalan I saw it, but it was somehow confusing that the NOTE is in version 3.6.0 but the error occurred later in 3.7.0.

Do you mean that the the change in the metadata update semantics (and side option overrideMetadata) didn't happened in 3.6.0 but in the 3.7.0 (i.e. the note in the release notes was misplaced)? That's weird and it should be checked if you confirm that is the case.

From which version did you update to 3.7.0?

[tstorek]

@fgalan I am sorry. I just doubled checked and apparently, we accidentally skipped some versions here although 3.6 was already released more than a half year ago and I was pretty sure that it was updated in between. Sorry for that! Hence, no need to look into it again. I was probably in rush and like to apologize. Next time I goona read the notes more carefully!

[fgalan]

@fgalan I am sorry. I just doubled checked and apparently, we accidentally skipped some versions here although 3.6 was already released more than a half year ago and I was pretty sure that it was updated in between. Sorry for that! Hence, no need to look into it again. I was probably in rush and like to apologize. Next time I goona read the notes more carefully!

Dont' worry :)

The bottom line is that if you upgrade (for instance) from 1.0 to 1.3 you not only have to check the release notes in 1.3, but also in other versions in the upgrade path (1.1 and 1.2 in this case).