Problem/Motivation

Note: This is both a bug ("Computed bundlie fields are broken") and a feature request ("Introduce the notion of computed field storage definitions") so landing on "task" as a compromise.

Because every field definition - including bundle fields - require an accompanying field storage definition, you also need to provide a field storage definition for computed bundle fields even though a computed (bundle) field does not require any storage. Because field storage definitions do not have the notion of "computed", this means that schema tables or columns will be created for those computed fields.

This can be worked around by marking the field storage definitions as having "custom storage", but that is a different semantic and is really just a workaround.

Proposed resolution

This is postponed on #2935932: Add a FieldDefinition class for defining bundle fields in code..

Introduce the notion of "computed" to field storage definitions.

Comments

tstoeckler created an issue. See original summary.

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
commented
Issue summary: View changes
Related issues: +#2935932: Add a FieldDefinition class for defining bundle fields in code.
jibran’s picture

jibran
he/him
Primary language Urdu
Location Toronto, Canada
commented

Might be a duplicate of #2986634: Discuss the role of field storage definitions for computed fields.

geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented

Thanks for linking the other issue. I'd prefer this as it has a workable proposal.

geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented

To make my assumptions explicit and avoid misconcepts:
* a) A computed field may or may not use sql storage. Having a computed field in DB to ease queries has valid use cases.
* b) A computed field may or may not use custom storage. Currently a field that wants field custom storage has to declare as computed and save in the (pre|post)save method. This has relevant use cases but should get better DX.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
commented
Title: [PP-1] Support computed bundle fields by adding the notion of computed field storage definitions » Support computed bundle fields by adding the notion of computed field storage definitions

Parent issue fixed.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

🎉

jibran’s picture

jibran
he/him
Primary language Urdu
Location Toronto, Canada
commented
Related issues: +#2932273: Figure out how to implement configurable computed fields

Maybe another duplicate #2932273: Figure out how to implement configurable computed fields

jibran’s picture

jibran
he/him
Primary language Urdu
Location Toronto, Canada
commented

#2981047-32: Allow adding computed bundle fields in Views is kind of doing this.


  /**
   * {@inheritdoc}
   */
  public static function bundleFieldDefinitions(EntityTypeInterface $entity_type, $bundle, array $base_field_definitions) {
    $fields = parent::bundleFieldDefinitions($entity_type, $bundle, $base_field_definitions);

    if ($bundle === $entity_type->id()) {
      // @todo Use the proper FieldStorageDefinition class instead
      //  https://www.drupal.org/node/2280639.
      $storageDefinition = FieldStorageDefinition::create('string')
        ->setName('computed_bundle_field')
        ->setTargetEntityTypeId($entity_type->id())
        ->setComputed(TRUE)
        ->setClass(ComputedTestBundleFieldItemList::class);
      $fields['computed_bundle_field'] = FieldDefinition::createFromFieldStorageDefinition($storageDefinition)
        ->setLabel(t('A computed Bundle Field Test'))
        ->setComputed(TRUE)
        ->setClass(ComputedTestBundleFieldItemList::class);
    }

    return $fields;
  }
jibran’s picture

jibran
he/him
Primary language Urdu
Location Toronto, Canada
commented
Related issues: +#2981047: Allow adding computed bundle fields in Views

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.

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.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.