Right now each field is multi-valued by default as we enforce this structure on all of our fields. This creates one intermediate, unused layer for all single-valued fields what has a performance impact memory and speed wise.

Considering we usually have quite some single-valued fields I think we should consider dropping the multi-valued enforcement for performance.
Related issue: #1869562: Avoid instantiating EntityNG field value objects by default

Impact:
You cannot rely on being able to do $entity->field[0] any more to get the first field item. You might have to do $entity->field instead. Still, we could support $entity->field->value to always work such that code won't break if you change a single valued field to become multiple valued. The other way round it breaks though.
Then, another question is whether we want to allow single valued fields for configurable fields (=field API fields) also. We could leave this possibility API-only and only allow developers to create them such that field API could continue to work on top of multiple-valued fields only.
Having single-valued fields would make some things easier also though. E.g. when serializing to JSON-LD (not drupal json-ld) I assume we could use the information which field is supposed to be single valued. Also, when I think of e.g. token replacements implemented on top of that, we'd naturally want single valued fields to appear single valued in a token browser... (related: #1869582: Leverage the Typed Data API for token replacements)

CommentFileSizeAuthor
#7 d8_field_single.patch39.83 KBfago
#7 d8_field_single.interdiff.txt10.46 KBfago
#6 d8_field_single.patch16.83 KBfago
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented
Issue tags: +Performance, +Entity Field API, +typed data

tagging

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented
Issue summary: View changes

Updated issue summary.

yched’s picture

yched CreditAttribution: yched commented

Ouch. I'm really not looking forward to changing the internal format of Field API fields depending on whether they are mono or single valued :-/.
The whole code base and storage relies on the fact that mono is treated as a degenerate case of multi. I don't see us adding "it depends" code all around the place

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented

ad #2 - as said above:

We could leave this possibility API-only and only allow developers to create them such that field API could continue to work on top of multiple-valued fields only.

Thus, we could support single-valued entity fields only for not-configurable fields, i.e. fields not handled by the field API?

yched’s picture

yched CreditAttribution: yched commented

Yeah, I was reacting to "Then, another question is whether we want to allow single valued fields for configurable fields (=field API fields) also".
Of course, if configurable fields are left untouched, I have no objection :-).

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented
Title: Consider supporting single valued EntityNG fields » Support single valued EntityNG fields
Issue tags: +Typed sanity

As discussed during drupalcon, we want to do it.

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented
Status: Active » Needs review
FileSize
d8_field_single.patch16.83 KB

Rolled a patch for this one. Without any field implementing it yet.

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented
FileSize
d8_field_single.interdiff.txt10.46 KB
d8_field_single.patch39.83 KB

So this implements a single field for node.title. It factors Field::access() out into a helper class to ease code-reuse. Besides that naming of all the field data type classes need work (in general), e.g. it's type "string_field" with class StringItem - but that's best cleaned up as part of #2023563: Convert entity field types to the field_type plugin as there data types for field item's will become field_item:string anyway.

Let's see how that goes.

Status: Needs review » Needs work

The last submitted patch, d8_field_single.patch, failed testing.

yched’s picture

yched CreditAttribution: yched commented

Since this is apparently renaming Field to FieldItemList (which is a *very* good thing IMO - see my rant in #2019601-72: Rename config Field / FieldInstance structures ?), this completely changes the problem space around our naming issues.

I closed #2019601: Rename config Field / FieldInstance structures ?, and started a new proposal at #2051923: Rename \Drupal\Core\Entity\Field\Field, related subclasses and interfaces to *FieldItemList.

It's not clear when this patch here is going to be ready, though. Do you think it would be doable that we do the Field / FieldItemList rename separately ?

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented

As discussed #2051923: Rename \Drupal\Core\Entity\Field\Field, related subclasses and interfaces to *FieldItemList goes with FieldItemList now, what means the we probably would have to implement the FieldItemList interface with a single field item here. So that would probably put as to not breaking the public API contract of content entities never breaking the "entity - itemlist -item" structure, but just saving the itemlist object instance if we know there will be only one anyway. I.e., this would boil down to a performance improvement patch without any API changes.

As an alternative, we could allow entities to consist of fieldItemLists or fieldItems directly, what should generally work out, but opens the question on how we'd deal with stuff like access() being part of FieldItemListInterface but not in FieldItemInterface.

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented
Issue summary: View changes

Updated issue summary.

jibran’s picture

jibran
he/him
Primary language Urdu
Location Sydney, Australia
CreditAttribution: jibran commented

There is no EntityNG in core now.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented
Title: Support single valued EntityNG fields » Support single valued Entity fields
Priority: Normal » Major
Issue tags: +beta target
fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented
Version: 8.x-dev » 9.x-dev

This won't happen for D8.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented
Version: 9.x-dev » 8.x-dev

There's nothing actually stopping it going into 8.x though except for time/interest, I'd like to keep the 9.x queue as short as possible with things that really can't possibly ever happen in 8.x under any circumstances.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett commented
Version: 8.x-dev » 8.0.x-dev
xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm commented
Version: 8.0.x-dev » 8.2.x-dev
Issue tags: -beta target

This issue was marked as a beta target for the 8.0.x beta, but is not applicable as an 8.1.x beta target, so untagging.

I've moved the issue to 8.2.x since it could be possible to implement this with BC in a minor.

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

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now 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.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now 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.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.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.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.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.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

bradjones1’s picture

bradjones1
Primary language English
CreditAttribution: bradjones1 commented

I'm curious if the ship has long sailed on the idea of supporting single-ordinality fields, as Drupallers everywhere have now gotten used to ->first() on fields?

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.