Discussion: Should collection IDs be assigned for collections in the TES?

[tmadlener]

Currently collections only have a valid (i.e. != -1 or ffffffff) collection ID if they are read from file, as it gets assigned only when we put collections into the Frame for writing. This can lead to issues when trying to use the collectionIDs as unique identifiers for collections (e.g. key4hep/k4MarlinWrapper#235).

It should be fairly straight forward to assign collection IDs when collections are put into the TES, since the name for persisting to file is also the name we use for identifying it in the TES. IT might be necessary to expose some API call to provide the hash from the name.

The question is: Do we want / need to assign valid collection IDs when adding collections to the TES? Currently, we do not document whether this is defined or not, so at the least we should document expectations around this.

[tmadlener]

key4hep/k4MarlinWrapper#236 at least currently seems to imply that we actually need this assignment for things to work properly.

[tmadlener]

As discussed at todays EDM4hep meeting the main purpose of the podio::ObjectID is persisting relations without having to do any pointer chasing. Hence, it was never intended to be used outside of that purpose. Additionally, assigning a collection ID outside of a Frame also breaks the contract that only collections owned by a Frame have a collection ID, and checking ownership via collection ID would be no longer possible.

On the other hand for the user putting things into the TES or a Frame is effectively the same thing, as in both cases they hand over ownership and it doesn't matter too much where the ownership goes. Collision checking when handing over to the TES is not as easy as it is with the Frame (at least in the current implementation) as the TES hashes one collection at a time and does not keep track of which collections have been added.

We might consider making the ObjectID non-public in podio generated EDMs, but we are not entirely sure whether it's feasible. That discussion will happen in podio.

[tmadlener]

We discussed this again at todays Key4hep meeting. The conclusion that the ObjectID should not be public (and relied on for anything) still stands. However, we also concluded that there should be a way to get from an Object to the collection it belongs to if the collection is known to the TES (or the Frame). This internal implementation could then still use ObjectIDs for a quick lookup or fall back to a rather elaborate std::find.

With that in mind I think it still makes sense to assign a collectionID when a collection is put into the TES because from a mental model point of view it's effectively the same thing (as already stated above). Making this possible will require a bit of work in podio and also k4FWCore as currently the access pattern is object -> id -> name, but it should be straight forward to eliminate the id part.