Postponed on #2283977: Create a new ConfigEntity type for storing bundle-specific customizations of base fields, which is introducing the BaseFieldOverride class described in this issue.
Problem/Motivation
- When a new 'base_field_override' config entity is created, BaseFieldOverride::preSave() calls the target entity type's storage handler's onFieldDefinitionUpdate() method, passing it the base field definition as the "previous" definition. And similarly, when the override config entity is deleted, BaseFieldOverride::postDelete() calls onFieldDefinitionUpdate, passing it the base field definition as the "new" definition.
- However, if it happens that a base_field_override config entity is being added to or deleted from a site that also implements an override via ContentEntityInterface::bundleFieldDefinitions(), then the above behavior is incorrect, since the previous definition prior to base_field_override insertion and the new definition after base_field_override deletion is the one returned by ContentEntityInterface::bundleFieldDefinitions(), rather than the base definition.
- The above might be an extreme edge case, because using ContentEntityInterface::bundleFieldDefinitions() rather than config to override base field definition is specifically intended for when you need you content entity type completely decoupled from config, in which case there shouldn't be code adding and removing base_field_override config entities for it.
- Also, it's not really clear what FieldableEntityStorageDefinitionInterface::onFieldDefinitionUpdate() is even for. The only implementation of it in HEAD is a completely empty function, even after #1498720: [meta] Make the entity storage system handle changes in the entity and field schema definitions. Perhaps we should consider removing it? Do storage handlers need to be notified of non-storage-related changes to field definitions?
Proposed resolution
Discuss the above and figure out what to do.