- Issue created by @fmb
- @fmb opened merge request.
- Status changed to Needs review
almost 2 years ago 9:21am 8 March 2023 - 🇫🇷France fmb Perpinyà, Catalonia, EU
- We might need a more generic way than
$plugin_entity_data[$mapping]
to update references. - This only works when we load entities, not when we save them (I do not have the need for it currently, nor could I test this case).
- We assume entity E and E' use the same prefixes.
- We might need a more generic way than
- 🇫🇷France guignonv
It seems a bit complicated. And when it is complicated, it could mean the used approach is not good.
Here, I don't understand what your are trying to achieve. From my perspective, you would not load E(37) but rather E(A37) or E(B37) which would reference E' with the appropriate identifier then.I need more explanation on a concrete case.
- Status changed to Closed: won't fix
over 1 year ago 5:41am 6 April 2023 - 🇫🇷France guignonv
To sum up the discussion we had:
A use case is when you have a single xntt type that regroups several sources using xnttmulti and uses a group prefix for each source in order to distinguish them. All data identifiers coming from the "A" source will be virtually prefixed with "A-" and "B" with "B-". So when "A" provides an objectid of 77 for instance, the configured xntt will receive the identifier "A-77" and it will query the A source without that identifier (ie. "77") to get the object. If "B" also has an object using the 77 identifier, it will not conflict as it will not queried by xnttmulti (since the xntt type groups have been configured properly).
But when an "A" object has id references to other "A" objects, for instance a ".parent_id" field, the returned value for that reference could be, for instance, "76" and not "A-76" because the "A" source does not have to know that we work with "groups" on the xnttmulti side, in order to differentiate data sources. On the other hand, xnttmulti does not know which field is an internal reference to a given source object identifier. And xnttmulti does not know which fields could be returned by a source as well. So the knowledge of "how to use a given object identifier" is only owned by the xntt type admin.
Therefore, from my point of view, it's something that should be managed in xntt field mapping. So far, we got 2 mappers: "Simple" and "JSON Path". There should be a new mapper plugin that could be able to do some operations on fields values, like combining them and extract parts of them.
For instance, if our xntt from A returns 2 fields: "A.id" and "A.parent_id", in our example with xnttmulti and the group configuration, the A source would return:
["id" => 77, "parent_id" => 76]
And xnttmulti (with group) will turn it into:
["id" => "A-77", "parent_id" => 76]
The new mapper should be able to have an entity reference field (Drupal field) identifier mapped to:
substr(id,0,2) . parent_id --> 'A-76'
Then the reference to the parent xntt would be resolved to the 'A' source.
I would suggest the "Complex" field mapper (in contrast with the "Simple" field mapper ;) ) would allow a syntax like:
"bla{some_field_identifier}bliblu{$.some.json.path}bloblebly{somt_other_field#some_filter_to_define(with, parameters)}"
and in our example case we would map parent entity id field to:
"{id#substr(0,2)}{parent_id}"But it is a suggestion and the syntax need to be well though.
- 🇫🇷France guignonv
The solution is to use an external entity field mapper such as External Entities String Functions and JSONPath Field Mapper → to add the needed prefix to the needed fields. With that mapper, you can extract the prefix of interest from a field (like the ID field) and prepend it to another field.
With xnttstrjp, it could look like something like that:substr($.id, 0, 2) . $.somefield