Before #1497374: Switch from Field-based storage to Entity-based storage, configurable $field structures were not tied to a specific entity type, only $instance was.
So, since both $field and $instance implement FieldDefinitionInterface, getEntityType() was left out of it.

But now, a configurable $field *is* tied to an entity type. Base fields are tied to an entity type as well.
So there should be a FieldDefinitionInterface::getEntityType() ?

(note: $field and $instance, by being ConfigEntities, already have an entityType() method, we should disambiguate - so maybe getTargetEntityType() ?)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fago’s picture

Yeah, I think that would be consistent on how we treat field names already, i.e. the field definition knows about its context. This is already the case for configurable fields, and I don't see a problem with doing it for non-configurable fields also.

FieldDefinitionInterface::getEntityType() would be nicer, but yeah to disambiguate I'd vote for getTargetEntityType() also.

yched’s picture

Issue tags: +Novice

Easy task

swentel’s picture

Status: Active » Needs review
FileSize
2.9 KB

Status: Needs review » Needs work

The last submitted patch, 3: 2134967-3.patch, failed testing.

swentel’s picture

Status: Needs work » Needs review

3: 2134967-3.patch queued for re-testing.

swentel’s picture

FileSize
2.79 KB

Status: Needs review » Needs work

The last submitted patch, 6: 2134967-6.patch, failed testing.

swentel’s picture

Status: Needs work » Needs review

6: 2134967-6.patch queued for re-testing.

The last submitted patch, 3: 2134967-3.patch, failed testing.

yched’s picture

Status: Needs review » Reviewed & tested by the community

Yup. Thanks!

chx’s picture

Status: Reviewed & tested by the community » Needs review

Wouldn't getParentEntityType be better? Just because typed data uses the parent concept and these are not reaaaaally references. I am not here to bikeshed but this name does not mesh well with either concerns.

fago’s picture

hm, personally I'd favour the target variant. The entity is not the parent of a field definition, but I could see a field definition targeting a certain entity type (so it references an entity type).

yched’s picture

Status: Needs review » Reviewed & tested by the community

+1 on "target" too, for the reason @fago mentioned, + I advocate to keep TypedData API as "in the back" as possible, so I'm not too keen on modelling domain interfaces on it :-)

Temptatively setting back to RTBC ?

webchick’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +API addition

Hm. The word "Target" means nothing to me, personally. It sounds like something an Entity Reference field would have, but this is just a regular ol' field definition. So colour me confused. :( ("Parent" doesn't really help either, FWIW.)

$field->getEntityType() sounds perfect to me, personally. But it sounds like this was deliberately not chosen because it already exists (from "(note: $field and $instance, by being ConfigEntities, already have an entityType() method, we should disambiguate - so maybe getTargetEntityType() ?)" in the issue summary). But then I do not understand what the difference is between this method and $field->getEntityType().

Could we maybe add some tests to clarify..? Since there's nothing in core using this method it's hard to grok for a newcomer to field/entity API.

yched’s picture

@webchick:

$body_field->entityType() == 'field_entity' (method from EntityInterface - you're an entity, what's your entity type ?)
$body_field->getTargetEntityType() == 'node' (method from FieldInterface - you're a field, which entity type are you attached to ?)

ar-jan’s picture

Maybe getHostEntityType() ?

yched’s picture

More broadly speaking:
- There are a lot of config entities that store something "related to an entity type", possibly related to "a specific bundle in this entity type".
- Those typically have 'entity_type' / 'bundle' properties in their CMI file, resulting in $entity_type / $bundle members in the corresponding ConfigEntity classes.
- We're looking for good accessor method names for those properties, considering that, by virtue of being a ConfigEntity, there already are entityType() / bundle() methods (for "what is *your own* entity type / bundle as an Entity).

Ideally each ConfigEntity that fits that pattern should not have to come up with its own method names. getHostEntityType() might kinda sorta work for fields since you could say that a field "is hosted" by an entity type (even though we currently don't use that specific terminology anywhere in code / comments / UI, so that would still feel weird IMO). But "hosted by" seems totally unfit to qualify the relation between, for example, an EntityDisplay and the entity type/bundle it is associated with.

In that sense, getTargetEntityType() / getTargetBundle() feel more neutral. "Those are the entity type & bundle I, as a piece of configuration, am talking about".

webchick’s picture

Ok, let's keep target (only other word that springs to mind is "attached" but that probably has other connotations in Field API), but update the docs to make it more clear how it's distinguished from getEntityType(). Something along the lines of #15 would work.

swentel’s picture

FileSize
3.16 KB

Needed major reroll - useless to have an interdiff.

yched’s picture

#19 works for me.

Suggestion to address @webchick's request in #18:

FieldDefinitionInterface::getTargetEntityType():

Returns the entity type this field is attached to.

This method should not be confused with EntityInterface::entityType() (configurable fields are config entities, and thus implement both interfaces):
- FieldDefinitionInterface::getTargetEntityType() answers "as a field, which entity type are you attached to ?", 
- EntityInterface::entityType() answers "as a (config) entity, what is your own entity type"

@return ...

?

swentel’s picture

FileSize
3.56 KB
911 bytes
chx’s picture

FileSize
2.11 KB
3.58 KB

1. webchick suggested attached 2. the doxygen suggested attached. So then let me suggest getAttachedToEntityType ...

yched’s picture

getAttachedToEntityType() ? hardly seems a win, it's ugly and doesn't mean anything...

amateescu’s picture

I also don't think getAttachedToEntityType() is an improvement. #21 is RTBC for me, unless @webchick has some input on the text from #20.

plopesc’s picture

FileSize
3.97 KB

Re-rolling #21, as commented with @swentel on IRC.

yched’s picture

Status: Needs review » Needs work
  1. +++ b/core/lib/Drupal/Core/Entity/EntityManager.php
    @@ -332,8 +332,12 @@ public function getFieldDefinitions($entity_type, $bundle = NULL) {
    +        $base_definitions = $class::baseFieldDefinitions($entity_type);
    +        foreach ($base_definitions as &$base_definition) {
    +          $base_definition['entity_type'] = $entity_type;
    +        }
             $this->entityFieldInfo[$entity_type] = array(
    -          'definitions' => $class::baseFieldDefinitions($entity_type),
    +          'definitions' => $base_definitions,
    

    This looks wrong ? $base_definition is a FieldDefinition object, not an array ?

  2. +++ b/core/modules/field/lib/Drupal/field/Entity/FieldInstance.php
    @@ -586,6 +586,7 @@ public function isConfigurable() {
       /**
        * {@inheritdoc}
        */
    +
       public function isDisplayConfigurable($context) {
         return TRUE;
    

    Oops.

plopesc’s picture

Status: Needs work » Needs review
FileSize
1.13 KB
3.76 KB

Addressing comments in #26

Xano’s picture

+++ b/core/lib/Drupal/Core/Entity/EntityManager.php
@@ -326,7 +326,7 @@ public function getFieldDefinitions($entity_type, $bundle = NULL) {
+          $base_definition->entity_type = $entity_type;

Is this the best way to fix this? $base_definition is a FieldDefinitionInterface, not an instance of a particular class.

yched’s picture

There are currently no setters on FieldDefinitionInterface, because FeidlDefinitioninterface is too generic (used for base fields, configurable fields, configurable field instances, and there are no setters that make sense for all of those). Separate mess.

baseFieldDefinitions() really returns an array of FieldDefinition objects, not FieldDefinitionInterface...

This being said - FieldDefinition::getTargetEntityType() returns $this->definition['entity_type'], so it doesn't look like $base_definition->entity_type = $entity_type will work.

The previous patch ($base_definition['entity_type'] = $entity_type) did work because FieldDefinition / DataDefinition has an ArrayAccess layer that writes to the protected $this->definition :-/

I'd say we need a setTargetEntityType() method on FieldDefinition...

plopesc’s picture

FileSize
1.57 KB
4.17 KB

Adding method setTargetEntityType() to FieldDefinition. Also adding NULL fallback for FieldDefinition::getTargetEntityType().

I considered adding setTargetEntityType() to Field and FieldInstance classes and moving it to FieldDefinitionInterface, but I think this i not useful because $entity_type is set in the constructor of these classes and I did not found any place in core where this value is modified.

Any thoughts?

Regards.

Status: Needs review » Needs work

The last submitted patch, 30: 2134967-30.patch, failed testing.

plopesc’s picture

Status: Needs work » Needs review

30: 2134967-30.patch queued for re-testing.

yched’s picture

Status: Needs review » Reviewed & tested by the community

Looks good to me. Thanks !

yched’s picture

Sigh; I suppose this should be getEntityTypeId() now...

Berdir’s picture

Title: FieldDefinitionInterface should include a getEntityType() » FieldDefinitionInterface should include a getTargetEntityTypeId()
Status: Reviewed & tested by the community » Needs work

Yes, it should.

plopesc’s picture

Status: Needs work » Needs review
FileSize
3.88 KB
4.2 KB

Renaming methods to getTargetEntityTypeId() and setTargetEntityTypeId()

Berdir’s picture

Thanks, can we make the method description abit more explicit and say that we're returning the ID of the entity type? See changes in #2180725: EntityInterface's return values are not or incorrectly documented for a similar improvement.

plopesc’s picture

FileSize
4.23 KB
1.2 KB

Changing docblocks.

The last submitted patch, 38: 2134967-38.patch, failed testing.

plopesc’s picture

38: 2134967-38.patch queued for re-testing.

Berdir’s picture

Status: Needs review » Reviewed & tested by the community

Thanks!

plopesc’s picture

catch’s picture

Status: Reviewed & tested by the community » Fixed

Committed/pushed to 8.x, thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.