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?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rlnorthcutt created an issue. See original summary.

generalredneck’s picture

Ron,

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.

rp7’s picture

Version: 8.x-1.0-alpha2 » 8.x-1.x-dev
Assigned: Unassigned » rp7
Category: Support request » Feature request
Status: Active » Needs review
FileSize
13.4 KB

Here's an attempt which allows this with a forward slash (/) notation.

Eg. to map to the "world" value in an array as following:

[
  'data' => [
    0 => [
      'hello' => 'world',
    ],
  ],
]

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.

rp7’s picture

Component: Documentation » Code
Wim Leers’s picture

Status: Needs review » Needs work

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.

Isn't this an unnecessary BC break? Arrays and \stdClass objects can be used interchangeably:

$a = ['foo' => TRUE, 'bar' => FALSE];
$b = (object) $a;
$c = (array) $b;
var_dump($a == $c);

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.

  1. +++ b/src/Entity/ExternalEntity.php
    @@ -136,13 +137,13 @@ class ExternalEntity extends ContentEntityBase implements ExternalEntityInterfac
    -  public function getMappedObject() {
    +  public function getMappedRawData() {
    
    @@ -156,27 +157,28 @@ class ExternalEntity extends ContentEntityBase implements ExternalEntityInterfac
    +    return $raw_data;
    
    +++ b/src/ExternalEntityInterface.php
    @@ -27,21 +27,21 @@ interface ExternalEntityInterface extends ContentEntityInterface {
    -  public function mapObject(\stdClass $object);
    +  public function mapRawData(array $raw_data);
    

    The interface would not need to be changed if we'd just do return (object) $raw_data;

  2. +++ b/src/ExternalEntityTypeForm.php
    @@ -153,6 +153,7 @@ class ExternalEntityTypeForm extends EntityForm {
    +      '#description' => $this->t('Map Drupal properties and fields with the raw data returned by the storage client. Nested values can be accessed by using the forward slash (/) separator.'),
    

    Map raw data returned by the external entity storage client to Drupal fields and properties on fields.

rp7’s picture

@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 :-)

Wim Leers’s picture

Perhaps in a separate issue :-)

Keeping scope tight keeps the patch simpler and commits easier to understand. +1 for doing that in a separate issue!

rp7’s picture

Status: Needs work » Closed (won't fix)

This was added to the 2.x branch - please see #2995140: External Entities 2.x.
Please create a new ticket for issues/features regarding this.