Computed fields don't show up as choices in search index fields

Thanks for reporting this issue!
This seems a bit of an unclean solution, though, accessing the definition directly. I'd just add && !$property->isComputed() to the condition instead – much cleaner using the interface provided.

However, the larger problem is that, according to a quick test, computed fields cannot be retrieved automatically any more than fields with custom storage can. So showing these properties as options would be just as confusing and pointless as for normal custom storage properties.
Or what's your rationale there?

It's clear that being able to index computed fields (or other fields with custom storage) would be useful in a lot of cases, that's not the issue. The issue, as said, is that it's just not possible to do generically with the current Drupal Core Entity API (as far as I know). Unless that's possible, making the fields available to be added to the index won't get us anything (except end user confusion).

For your use case, you can create a custom processor that just adds your property to the datasource (see \Drupal\search_api\Plugin\search_api\processor\AddURL for an example). That custom property can also be an entity reference, that's no problem – and then you should be able to use it in Search API Views just like any other indexed field (at least once #2789431: Allow the display of processor-generated fields/properties in Views is fixed).

If you have any general solution for this problem, please explain it.
Otherwise, I'd say we change the issue to a "Support request" and mark it "Fixed".

I stumbled upon this issue while experimenting with computed fields. Let me describe my use case.

I want to expose the year of publication of nodes as facets on a search delivered by search_api, on an index in Elasticsearch with the elasticsearch_connector module, and (obviously) the facets module. I thought I could accomplish this by indexing the date and then there would be a convenient option in facets to do this, but there doesn't seem a way (yet) to make a facet from a part of the indexed date, or I just couldn't find it :)

So, being pretty new to D8 but quite experienced with D7, I remembered the possibility to add 'extra' fields without any storage requirements in D7, searched for something similar in Drupal 8, and ended up with the computed fields as described on https://www.drupal.org/node/2112677. Although the guidelines on that page did not seem to be entirely correct, with some trial and error I managed to create a created_year property on nodes (derived from the value of the 'created' property), which gets successfully indexed by search_api when the patch from this ticket is applied. The biggest pitfall for me was the example BixProfileCurrentCompany class on the documentation page. search_api's Utility\FieldsHelper::extractFieldValues() expects the $data to be 'iterable' (it loops over it with a foreach) when it's a list, but the example BixProfileCurrentCompany does not properly initialize a list on construct, although it extends FieldItemList, so eventually no values were extracted because there was nothing to iterate through.

The essential pieces to create the computed field for my use case follow below. They still need polishing, and they currently live in a custom module named 'ocmwle_common', please don't pay attention to that.

src/Plugin/YearCreated.php:

<?php

namespace Drupal\ocmwle_common\Plugin;

use Drupal\Core\Datetime\DateFormatterInterface;
use Drupal\Core\Field\FieldItemList;
use Drupal\Core\TypedData\TypedDataInterface;
use Drupal\node\Entity\Node;

class YearCreated extends FieldItemList {

  public function __construct($definition, $name = NULL, TypedDataInterface $parent = NULL) {
    parent::__construct($definition, $name, $parent);

    $this->extractYear();
  }

  public function getValue($include_computed = FALSE) {
    $this->extractYear();

    return parent::getValue($include_computed);
  }

  private function extractYear() {
    /** @var Node $node */
    $node = $this->getEntity();
    $created = $node->getCreatedTime();

    /** @var DateFormatterInterface $dateFormatter */
    $dateFormatter = \Drupal::service('date.formatter');
    $year = $dateFormatter->format($created, 'custom', 'Y');

    $offset = 0;
    $this->list[$offset] = $this->createItem($offset, $year);
  }
}

ocmwle_common.module:

<?php

use Drupal\Core\Entity\EntityTypeInterface;
use Drupal\Core\Field\BaseFieldDefinition;
use Drupal\ocmwle_common\Plugin\YearCreated;

/**
 * Implements hook_entity_base_field_info().
 */
function ocmwle_common_entity_base_field_info(EntityTypeInterface $entity_type) {
  if ($entity_type->id() === 'node') {
    $fields = [];

    $fields['created_year'] = BaseFieldDefinition::create('integer')
      ->setLabel(t('Created year'))
      ->setDescription('The year of the created date (computed)')
      ->setComputed(TRUE)
      ->setClass(YearCreated::class);

    return $fields;
  }
}

I am attaching an updated patch for search_api, which follows the advice of drunken monkey in #5.

Regarding the last comments in #8, I am too new to D8 to judge wether it is possible or not to do this generically with the current Drupal Core Entity API. In my specific case, it eventually seemed to work. If you have particular cases you know that do not work correctly, please share and I might contribute some time to look at them.

Huh, you're right, this does look like it should actually work. I had merely happened to test with the "Path" field (the only computed field in Core, as far as I can see), and that just seems to be not implemented properly (for this use). But it might actually work with most other computed fields – not really a way to be sure.

We should, however, exclude the "Path" field, so it doesn't cause confusion. I don't like to do this in general, but it's in Core after all, and otherwise we're bound to get some bug reports for that.
Also, I reformatted a bit to get rid of the overlong line.

Revised patch attached. Please review whether it works correctly for you and I can commit.

Thanks for reporting back with this!
Anyone else want to test the patch?

I don't like that its two nested if statements but I understand you did this because of readability so RTBC imho.

Good to hear, thanks for reviewing!
I'm not sure I like it, either, but I guess we can go with it. (Even though I wonder why I didn't have the two ifs in the other order …)
Committed.
Thanks again, everyone!

I cant get this patch to work with views? I cannot add a computed field to a search view successfully. Does this work for anyone else?

Thanks
Sukanya

This should work, as far as I can see. Maybe the data type in question is just not supported?
Please create a new issue with your problem description and a bit more details.
(Would be good to hear from others here, though, whether this works for them. I don't have a computed field (other than "Path") available for testing.)

Thanks for the response.

This is the error I got

Notice: Undefined index: in Drupal\views\Plugin\views\field\Field->getFieldStorageDefinition() (line 332 of core/modules/views/src/Plugin/views/field/Field.php).
Drupal\views\Plugin\views\field\Field->getFieldStorageDefinition() (Line: 346)
Drupal\views\Plugin\views\field\Field->defineOptions() (Line: 99)
Drupal\search_api\Plugin\views\field\SearchApiEntityField->defineOptions() (Line: 17)
Drupal\views_field_metadata\Plugin\views\field\SearchApiEntityFieldWithMetadata->defineOptions() (Line: 138)
Drupal\views\Plugin\views\PluginBase->init(Object, Object, Array) (Line: 102)
Drupal\views\Plugin\views\HandlerBase->init(Object, Object, Array) (Line: 115)
Drupal\views\Plugin\views\field\FieldPluginBase->init(Object, Object, Array) (Line: 177)

when i check the Drupal\views\Plugin\views\field\Field->getFieldStorageDefinition() method, there is a specific condition to get the definitions for only non-computed fields which is why the view is failing,

Thanks,
Sukanya

I would like this issue to be reopened. The approach taken in patch 10 is making too big of assumptions about not being able to index fields that have custom_storage set to TRUE. Here is some example code that does NOT work with the current patch because the field can't be selected:

Execute this php script:

$content_type = NodeType::create(['type' => 'some_new_content_type']);

// Create field storage
$field_storage = [];
$field_storage['id'] = 'node.some_field_with_custom_storage' ;
$field_storage['field_name'] = 'some_field_with_custom_storage';
$field_storage['type'] = 'text_long';
$field_storage['entity_type'] = 'node';
$field_storage['custom_storage'] = TRUE;
$field_storage = FieldStorageConfig::create($field_storage);
$field_storage->save();

// Create a field with the custom storage
$drupal_field = FieldConfig::create([
 'field_storage' => $field_storage,
 'bundle' => 'some_new_content_type',
 'label' => 'Some field label',
 'settings' => array('display_summary' => TRUE),
 ]);
$drupal_field->save();

In some_module.module

function some_module_entity_storage_load(array $entities, $entity_type) {
  if ($entity_type == 'node') {
    foreach ($entities as $entity) {
      if ($entity->type == 'some_new_content_type') {
        $entity->set('some_field_with_custom_storage', 'some random text', FALSE);
      }
    }
  }
}

I've attached my purposed solution as a patch. Now you can add 'some_field_with_custom_storage' field to the index, and if you index the nodes, it will index properly. Thoughts?

The issue really is in Drupal core in that you can create fields where you can not retrieve their values via typeddate api, but we can not rely on checking if something has custom storage. I think we need to just exclude known fields until core api allows us to effectively check if it can be indexed.

Perhaps I should open a new issue for this?

@pwaterz: The assumption that fields that have custom storage can not be indexed, was there already. I think it's better to open a new ticket to change something regarding the other assumption.

Will do

Here is the patch for Drupal 9

Here the patch for index_computed_properties