Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I have been able to get this working with the REST plugin. Top level values (id, name, etc.) are all working fine, however if I try to map to items that are nested inside a multivalue array, only blank is returned.
The JSON value is
editions[0].rarity
I've tried variations of these in the "Field mappings" settings:
- editions[0].rarity
- editions[0]->rarity
- editions[0][rarity]
- editions[0]['rarity']
Does this currently handle multiarray values for the mapping? Is there some format I am missing?
Comment | File | Size | Author |
---|---|---|---|
#3 | external_entities-field_mapping_subitems-2884788-3.patch | 13.4 KB | rp7 |
|
Comments
Comment #2
generalredneckRon,
I was just looking for this answer as well... as I was trying out some stuff from your presentation at TexasCamp. The answer is located here http://cgit.drupalcode.org/external_entities/tree/src/Entity/ExternalEnt...
So, currently, no, you cannot "map" items in external entities to anything but the top level items. We could however implement something very simular to how Migrate does with slash notation or xpath or something.
Migrate uses slash notation... such as field_source/0/value. Might be a worth looking into implementing.
Comment #3
rp7 CreditAttribution: rp7 for Government of Flanders commentedHere's an attempt which allows this with a forward slash (/) notation.
Eg. to map to the "world" value in an array as following:
One would enter the following mapping notation:
data/0/hello
.All the heavy lifting is basicly done by the Drupal core class
Drupal\Component\Utility\NestedArray
. For reasons unknown to me, the module is now converting data from the storage clients to objects when reading & converting them back to arrays when saving. I've changed this so arrays are always used.Comment #4
rp7 CreditAttribution: rp7 for Government of Flanders commentedComment #5
Wim LeersIsn't this an unnecessary BC break? Arrays and
\stdClass
objects can be used interchangeably:will print
TRUE
.Not making this change here will make this patch MUCH easier to review, and will make it much easier for future maintainers/contributors to understand what change is being made here.
Right now, the patch is very hard to review. I think the patch would only be half the size if you'd not make that big architectural change here.
The interface would not need to be changed if we'd just do
return (object) $raw_data;
Map raw data returned by the external entity storage client to Drupal fields and properties on fields.
Comment #6
rp7 CreditAttribution: rp7 for Government of Flanders commented@Wim Leers
OK - I'll adjust the patch ASAP so it adheres to the current interface (eg. work with objects).
I'm however not a fan of having to juggle around between objects & arrays. I really don't see the added value of converting incoming data to stdClass objects. It's rather an annoyance, as this particular issue were trying to solve, shows. Since were still in alpha, and BC is not necessarily required (right? and perhaps very hard to achieve looking at some other incoming patches?), I tought it would be a good idea to get rid of this once and for all. Perhaps in a separate issue :-)
Comment #7
Wim LeersKeeping scope tight keeps the patch simpler and commits easier to understand. +1 for doing that in a separate issue!
Comment #8
rp7 CreditAttribution: rp7 for Government of Flanders commentedThis was added to the 2.x branch - please see #2995140: External Entities 2.x.
Please create a new ticket for issues/features regarding this.