Add metadata to ItemAddedEvent

[spacemanspiff2007]

Currently an ItemAddedEvent event looks like that

{
  "type": "ItemAddedEvent",
  "topic": "openhab/items/TestString/added",
  "payload": "{\"type\":\"String\",\"name\":\"TestString\",\"label\":\"Label\",\"category\":\"text\",\"tags\":[\"Tag1\"],\"groupNames\":[]}"
}

The payload contains only a subset of the available item data.

Payload

{
  "type": "String",
  "name": "TestString",
  "label": "Label",
  "category": "text",
  "tags": [
    "Tag1"
  ],
  "groupNames": []
}

The Item definition additionally contains metadata

{
  "metadata": {
    "meta": {
      "value": "data"
    }
  },
  "type": "String",
  "name": "TestString",
  "label": "Label",
  "category": "text",
  "tags": [
    "Tag1"
  ],
  "groupNames": []
}

The metadata should also be included in the ItemAddedEvent

[splatch]

Association of item and metadata is loosely coupled so its not always 1:1 and it builds some kind of race condition especially during startup of the system when items and metadata could be loaded in parallel. How would you like this to be solved?

[spacemanspiff2007]

Association of item and metadata is loosely coupled ... and it builds some kind of race condition especially during startup of the system when items and metadata could be loaded in parallel.

I know and I still can't warp my head around why it is that way. Do you by chance have any explanation?

Would a possible solution be to just load the metadata before the items?
When loading items from file it could already be done that way: First add the item metadata and then add the item.

so its not always 1:1

I understand that that metadata is optional so the item has an optional relation to metadata.
Do you have an example where an item has more than one metadata?

[rkoshak]

Do you have an example where an item has more than one metadata?

It can happen all the time. Let's say I have a light that I want to expose to Google Assistant, configure Expire so the light turns off after 30 minutes, it has both a custom list litem widget and a custom standalone widget, and it's involved in a scene managed by a set of rules that rely on custom metadata.

That's five separate metadata entries for a use case that is not all that unusual.

And in some cases, particularly with custom Item metadata, it can be quite involved and complex since each metadata entry consists of of a namespace, an optional value, and an optional dictionary of an arbitrary number of name/value pairs (here is where metadata can become quite lengthy, much larger than the rest of the Item's record.

[splatch]

I know and I still can't warp my head around why it is that way. Do you by chance have any explanation?

@spacemanspiff2007 I do not, I can just draw my assumptions that metadata support was added later than items hence both are kept separate. Also from design perspective its easier to keep item and metadata registry separate, eventual correlation is made at rest resource level.
Above architecture leads to situation that item and metadata events are handled separately.

Would a possible solution be to just load the metadata before the items?

In theory yes, in practice not. By using ready markers it is possible to force specific load order so metadata is read first and then items. In case of xtext based stuff I think these are very closely related so it might be actually done all together. The practical aspect which makes it difficult is that this part of openHAB utilizes the "registry" pattern with multiple metadata and item providers. This means that you can have metadata providers added later by some sort of async startup sequence, hence framework itself can't make any assumptions here. Or maybe it can but only for "managed" elements which are managed by OH storage apis (here jsondb).

Do you have an example where an item has more than one metadata?

I do have items which use state description and some additional namespaces I use to ie. create dynamic items. So its completely natural as long as namespaces do not overlap.

I think that discussed case could be covered by specific event triggered when metadata association or disassociation is made. I think underlying metadata registry knows when an item or metadata is added and other end of relation is found as well. By this way you could have something like that:

{
  "metadata": {
    "meta": {
      "value": "data"
    }
  },
  "item": {
    "type": "String",
    "name": "TestString",
    "label": "Label",
    "category": "text",
    "tags": [
      "Tag1"
    ],
    "groupNames": []
  }
}

So its something which is distinct from Item or Metadata event which indicate domain elements. Association event would mean that there is a match between above.

[spacemanspiff2007]

Thank you for your detailed explanation - I understand it a little bit better now.

I do have items which use state description and some additional namespaces I use to ie. create dynamic items. So its completely natural as long as namespaces do not overlap.

I do have multiple namespaces, too but I did not realize that this results in multiple metadata objects.
But that is still something that could be modeled with a single mapping directly on the item.

Imho it boils down to the following question:
Are metadata objects always item bound?

---

So its something which is distinct from Item or Metadata event which indicate domain elements. Association event would mean that there is a match between above.

That would be sufficient as well. But in that case it's not necessary to pass anything else than the item name to the event since the event consumer has to query the full item definition through REST anyway.

[splatch]

Looking at this PR #2553 - it does introduce binding between item and metadata. At core level.

[spacemanspiff2007]

Shouldn't be metadata a property of an item instead of introducing a binding?
What do you mean by binding?

[J-N-K]

At the the time the item is added and the event is created, the associated metadata may already be present or not, depending on timing. Therefore this would not result in a reliable way to report metadata associated with the item.

Since no maintainer stepped up to support this, I'm closing the request here. It is in any way a duplicate, because if #3281 would be implemented, the metadata would also be part of the item and then part of the ItemAddedEvent.