Problem/Motivation

Follow-up to #2341357: Views entity area config is not deployable and missing dependencies. In that patch, we add the following hardcoded check in EntityManager::loadEntityByConfigTarget():

   // For configuration entities, the config target is given by the entity ID.
    if ($entity_type instanceof ConfigEntityTypeInterface) {
      $entity = $this->getStorage($entity_type_id)->load($target);
    }

    // For content entities, the config target is given by the UUID.
    else {
      $entity = $this->loadEntityByUuid($entity_type_id, $target);
    }

Proposed resolution

Instead of hardcoding this check, we could allow entity types to return their target identifier key.

Remaining tasks

Decide if this would be a worthwhile change following #2341357: Views entity area config is not deployable and missing dependencies.

User interface changes

None.

API changes

TBD

Postponed until

#2341357: Views entity area config is not deployable and missing dependencies

Files: 
CommentFileSizeAuthor
#3 2412983.patch700 bytesamateescu

Comments

xjm’s picture

Title: Views entity area config is not deployable and missing dependencies » Consider adding a method to indicate the entity type's target identifier key

Forgot to correct the issue title. :P

xjm’s picture

Status: Postponed » Active
amateescu’s picture

FileSize
700 bytes

@xjm, you said in #2341357-124: Views entity area config is not deployable and missing dependencies:

right, the idea is to ensure that config entities use their ID rather than their UUID.

PHP provides a nice way for this if we really want to ensure it :)

xjm’s picture

Uh. I don't think that's what I meant, exactly. :) Or at least, it's not what I was thinking about. I meant, ensure that we don't accidentally store UUIDs for config entities and thereby break config dependencies, with the default implementations, in messy cases like Views. If someone wanted to override some config service to do dependencies with UUIDs, uh go for it and have fun? Or something.

xjm’s picture

Basically, my thought here was that our distinction between configuration and content is arbitrary (e.g. taxonomy terms) and so providing API rather than hardcoding instanceof checks seems more sound and offers the potential for alternate implementations.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.