Spin-off from #2164601: Stop auto-creating FieldItems on mere reading of $entity->field[N]
Problem
The notion of "computed property" is pretty clear - typically, $field->field_ref->entity.
This is defined at the level of a property definition, for example in FieldItemInterface::propertyDefinitions() :
$properties['entity'] = DataReferenceDefinition::create('entity')
->setComputed(TRUE);
This means the property value will never be stored, and is lazy-computed on request by some custom code in the corresponding Data class.The notion of "computed field" is still quite shaky.
It can be defined at the level of a field definition, for example in FieldableEntityInterface::baseFieldDefinitions() :
$field['foo'] = BaseFieldDefinition::create('string')
->setComputed(TRUE);But the actual effect of that is quite unclear at the moment. The only sure thing is that storage will never try to store the field values.
Proposal
This is the current state of our discussions with @fago in Ghent. For clarity, this tries to expose the concepts of "computed properties" (pretty much OK in HEAD currently) and "computed field" (still largely TBD) side by side.
Computed property
Sample case: EntityReferenceItem->entity
Behavior: don't save or load the value of that property when saving/loading the items, the value is populated on read at runtime.
The existence of a computed property is not field-by-field, it is determined by the field type, in the propertyDefinition() method of its Item class. It necessarily relies on the property definition providing a custom property class that implements the "compute the value" logic.
Also, the schema() method will likely omit to declare a schema column for that property, so nothing can be stored for that property anyway (well, at least in SQL - schemaless storage probably require some code to remove the value before storing the entity).
Computed field
Sample case: a "back reference" field (a field that lists all the entities that have an entity_ref field pointing to that entity)
Behavior : don't save or load *anything*, we don't know whether there are items and how many, that will be determined on read at runtime.
--> In other words, the "computed" thing here is the FieldItemList.
This is field-by-field, specified by the individual field definitions, and is not tied to the field type. You can define a computed field of any existing field type. That necessarily relies on the field definition providing a custom FieldItemList class, that implements the "compute the existing items" logic.
This raises the question : how can a configurable field be made "computed", since the only way to specify that custom List class currently is in runtime code ? A back_ref field would typically be manually added by site admins, and would thus need to be configurable...
Also, the field type can happen to have computed properties, that's orthogonal. For example, a back_reference field could be a field of type entity_ref, with a computed ->entity property in each item that loads the referencing entity (that's for illustration's sake, in reality it would probably have more specific needs and be a separate field type that extends entity_ref).
In short, the two "computed" operate at different levels:
- computed field means : don't store anything, I'll tell you which Items exist at runtime
- computed property means : in each item that exist (however they happen to exist, stored or computed), don't store that property value, I'll tell you the value at runtime.