Problem/Motivation

While writing the mongodb content entity storage passing back stored data to ContentEntityBase was the biggest mystery. I have figured it out, I think.

Proposed resolution

Document the array. Add a todo.

Remaining tasks

The whole loadFromMongo method really badly wants to be documentation; this is the first half, up to creating the entity. Where do we put the second half?

Get someone (plach/berdir/fago) to verify the @todo . If correct then #2137801: Refactor entity storage to load field values before instantiating entity objects needs an issue summary update, I think. Ie. I know loadFromMongo works because Drupal\node\Tests\NodeViewLanguageTest and Drupal\node\Tests\NodeFieldMultilingualTest pass since I changed it to do what core does, I think at least -- but the question is, is this the only way?

User interface changes

API changes

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

chx’s picture

Issue summary: View changes
Berdir’s picture

+++ b/core/lib/Drupal/Core/Entity/ContentEntityBase.php
@@ -39,13 +39,18 @@
    * @todo: Provide a better way for defining default values.
+   * @todo: currently only LanguageInterface::LANGCODE_DEFAULT is supported
+   * see https://www.drupal.org/node/2137801

The referenced issue wouldn't change anything as far as how this is stored. What it would change that we would pass a $data array into loadFields() or how it is called again, and then collect the field values in an array instead of passing in an entity object and assign the f ield values to the entity object through the (slow) entity field API.

And it should be possible to already pass in an array with more than one translation directly to $values. I'll check the sql implementation again but I'm pretty sure we already do that for base fields, just not configurable fields (and none of those, default language or not), @plach might be better at answering this.

In your method, shouldn't the break on http://cgit.drupalcode.org/mongodb/tree/src/Entity/ContentEntityStorage.... be *inside* the if, otherwise it would stop after the first loop, wheter it found the default language or not?

chx’s picture

> In your method, shouldn't the break [snip]

Yes. It works because save already moves the default to be the first and it's just a safety against manual manipulation but thanks I fixed it.

plach’s picture

Title: ContentEntityBase::$values documentation is very poor » ContentEntityBase::__construct() lacks documentation
Issue tags: +Entity Field API
FileSize
1.34 KB

What about something like this? I documented all the constructor parameters instead, which should be more interesting for API consumers :)

Btw, I think the langcode level was added to $values after the $translations parameter was added. I think the latter is useless now and could be derived by the $values langcode keys. However that's a separate issue, I guess.

plach’s picture

FileSize
1.45 KB

Better docs for the last param.

chx’s picture

Sure, but I am 95% sure you can't pass translations in values, check the code in the constructor:

$this->$key = $value[LanguageInterface::LANGCODE_DEFAULT];
$this->entityKeys[$key] = $this->values[$field_name][LanguageInterface::LANGCODE_DEFAULT][0]['value'];
$this->entityKeys[$key] = $this->values[$field_name][LanguageInterface::LANGCODE_DEFAULT];

I tried to pass in non-default langcodes -- but perhaps when I tested that I still used en instead of LANGCODE_DEFAULT ? Perhaps. I will re-test, nonetheless, this is patch is a big step forwards, thanks. But I still would like to see some code which passes translated values in $values...

plach’s picture

It might be a good idea to add a test here.

jhodgdon’s picture

Status: Needs review » Needs work

I have not comment on the accuracy of the docs - will let others review that.

A few typos:

a)

+   *   values for the default entity language (e.g. 'en') should by be keyed

"by" should be dropped.

Also Please Do Not Use "e.g.", unless you want to punctuate it properly. Better not to use it, as half of the readers do not understand the difference between e.g. and i.e. If you insist on using it, the correct punctuation is:
(e.g., ...)

b)

+   *   with LanguageInterface::LANGCODE_DEFAULT. This does not affect actual
+   *   field values, for instance the default language value for the 'langcode'
+   *   field would be 'en' in this case.

This last sentence is a comma splice. Should be "... field values; for instance, the default...".

Berdir’s picture

@chx: #2137801: Refactor entity storage to load field values before instantiating entity objects has a patch now, note that it doesn't change anything about the constructor arguments, but will hopefully make it easier to understand how $values is built.

I think the issue that would be more interesting for you would be #2142885: Simplify ContentEntityBase internal field storage by removing special treatment for LANGCODE_DEFAULT, which would change $values from being first keyed by field name and then language to first language, second field name. Which I think would be a lot easier to create for you. That would be an API change, but I think you would be the only person affected by that and like +1 as it would simplify your implementation.

chx’s picture

xjm’s picture

Came here from #2436209: Test ContentEntityBase constructor called with multilanguage values.

+++ b/core/lib/Drupal/Core/Entity/ContentEntityBase.php
@@ -139,6 +139,24 @@
+   * @param array $values
+   *   A multidimensional array holding the entity field values for all the
+   *   available translations. The first key is a field name, the second is a
+   *   language code, the third is a delta, the fourth is a column name. Field
+   *   values for the default entity language (e.g. 'en') should by be keyed
+   *   with LanguageInterface::LANGCODE_DEFAULT. This does not affect actual
+   *   field values, for instance the default language value for the 'langcode'
+   *   field would be 'en' in this case.

This is hard to understand; an example would go a long way. Also at first glance it was unclear to me why this would be so drastically different from the parameter in Entity::__construct() until I realized that it's still keyed by field name with just a different/specific structure for the "values". So it might be good to mention the differences?

snehi’s picture

Status: Needs work » Needs review
FileSize
1.44 KB
468 bytes

Done as suggested in #8

Status: Needs review » Needs work

The last submitted patch, 12: interdiff-5-12.patch, failed testing.

snehi’s picture

Status: Needs work » Needs review
FileSize
468 bytes

Attaching diff

jhodgdon’s picture

Status: Needs review » Needs work

Thanks, but it doesn't look like #11 was addressed at all?

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.

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

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should 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.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should 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.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should 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.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.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.

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

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should 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.

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

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev
mimpro’s picture

Category: Bug report » Task
Issue tags: +Bug Smash Initiative

I am changing this category to TASK because this is more likely a task rather than bug, the code works well. If anyone disagree, feel free to change back to bug.

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

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should 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.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should 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: 9.5.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. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.