- Issue created by @rp7
- 🇷🇴Romania claudiu.cristea Arad 🇷🇴
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
- 🇧🇪Belgium rp7
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.
- 🇷🇴Romania claudiu.cristea Arad 🇷🇴
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
- 🇷🇴Romania claudiu.cristea Arad 🇷🇴
We can add a hook somewhere, so a third party might do whatever they want, including storing more info somewhere