Keeping track in which field the reference is made

The goal was to keep the table as compact as possible and I didn't see any reason to store also the fields. Probably, if we do, we should store also in the JSON field but is that worth it? Right now I don't see a use case

Just putting my use-case out here: we have a few big content types with a lot of fields and nested paragraph structures. Content comes and goes (unpublish) quite frequently. Before our users unpublish content, they want/need to verify if it's not actively being used (referenced) anywhere. It makes life a lot easier for them to immediately see from which field the other entity is referencing. It's more or less a "killer" feature for them.

Thinking more... with the current architecture is not possible because an entity might refer the same target via 2 different fields:

node(nid456) -> field_term -> taxonomy_term(tid123)
node(nid456) -> field_other_term -> taxonomy_term(tid123)

But currently, we only store once the relation between node(nid456) and taxonomy_term(tid123). We don't care which was the field, we're only interested if the relation exists. But did you try https://www.drupal.org/project/entity_usage → , that stores also the fields

We can add a hook somewhere, so a third party might do whatever they want, including storing more info somewhere

No input here. Should we close this?

Sorry for going AWOL. This completely fell of my radar.

We can add a hook somewhere, so a third party might do whatever they want, including storing more info somewhere

That sounds like an option. Where do you think this hook should invoked? My first thoughts tell me TrackPluginBase::getTargetEntities().

And with "somewhere" I guess you don't mean in the track_usage table. (but I guess - with custom code - I could add an extra colum in there).

Maybe we can still add it in the JSON field. Right now w path element looks like

node:28238:76623

We probably can make it look like:

node:28238:76623:field_ref

But we need a MR. And the upgrade path could be problematic