Simplification and storage saving potential for associations?

[Zehvogel]

This might be more of a podio technicality but I think this is the better place to discuss this...
In most cases associations between edm4hep objects, like the MCRecoParticleAssociation will always be associations between objects of a collection A and a collection B e.g. between PandoraPFOs and MCParticles. However, we store the collection ID separately for every single entry in the association collection, even though they should all have the same collection ID.
It might be worthwhile to consider only saving the collection ID once and check for consistency during creation of the association collection... This would also have caught something like key4hep/k4MarlinWrapper#113 earlier.

[tmadlener]

This is probably more of a podio technicality indeed ;) I am not sure if this is worth the effort, but maybe you have a more specific use case (or an example of where this would benefit things in general) in mind?

A few considerations from my side:

• The space savings (on disk) are probably very small since compression will kick in and have a very easy job to essentially do what you described.
• In it's current form relations (and by extension associations and subset collections) require only one mechanism to handle effectively everything. Hence, only having the indices and storing the collection IDs separately, requires the implementation of a separate mechanism just to handle associations, and I would rather not complicate the podio backend(s) further, unless there is a (very) compelling use case to do so.
• Broken associations when using edm4hep input  k4MarlinWrapper#113 is (more or less) unrelated to this. We could have checked for invalid collection IDs, but simply checking for the same ID would have succeeded, since all collection IDs are initialized to the same value.