Provide an API to temporarily associate data with an entity

I think we could do a property_exists() in the magic __set() method and then throw deprecated warning. Checking in the __get() may not catch it b/c.

->original has its own issue to be deprecated in favor of setters/getters.

I think we should add the API, then open a follow-up to add a deprecation warning just to see what happens and then as part of that open specific issues to convert usages in core to that.

I'm also open to discussing to deprecate $content_entity->$field_name in favor of supporting only get()/set(). I'm not sure yet about field properties.

See #1977266: Fix ContentEntityBase::__get() to not return by reference for a special case of __get() that we can likely not do anymore on its own but we might want to focus on the cases that require it to be by reference here first as they are probably the weird ones.

What about a seperate repository service or factory instead of adding additional responsibilities to EntityInterface. Could look like something like the following:

/** @var EntityTemporaryDataRepositoryInterface $temp_data */
$temp_data = \Drupal::service('entity.temporary_data_repository');
$temp_data->get($entity, 'foo');
$temp_data->set($entity, 'foo', 'bar');

/** @var EntityTemporaryDataRepositoryInterface $temp_data */
$temp_data = \Drupal::service('entity.temporary_data_factory')->getRepsitory($entity);
$temp_data->get('foo');
$temp_data->set('foo', 'bar');

I like:

/** @var EntityTemporaryDataRepositoryInterface $temp_data */
$temp_data = \Drupal::service('entity.temporary_data_factory')->getRepository($entity);
$temp_data->get('foo');
$temp_data->set('foo', 'bar');

a lot.

Especially as we could just potentially wrap it in a decorator when we need to access the additional properties:

$entity = new TemporaryMutableEntity($entity, \Drupal::service('entity.temporary_data_factory'));

However the disadvantage of keeping it separate from the entity itself is while it ensures that lazy builders could use "pack()" the entity back to array('entity_type', 'entity_id'), the problem is that when code actually relies on that there is no way anymore to see if the entity was modified.

e.g. what I used in a proof-of-concept while developing BigPipe was to serialize() the entity and serialize() a freshly loaded entity and compared those to see if it was modified in some way.

We could also allow to add a list of EntityModifiers - instead.

While that is still arbitrary, it is at least consistent.

e.g.

What about:

$modifier = new EntityModifier();
$modifier->set('_initialPublished', TRUE);
$entity->addModifier($modifier);

A get on an unused property would then ask if any modifier has the property and return it if it is there.

Though that does still not solve the problem of when an entity is reloaded, though e.g. the _initialPublished should not even persist for longer than the entity's lifetime.

---

So we have two things to take into account here:

• a) Ensure that properties survive a reload of the entity (for certain cases, others are relying on the exact object instance).
• b) Ensure that a diff of original entity vs. modified can still be retrieved somehow.

Still brainstorming here ...

I think the problem we have is that the entity has a fixed interface and we want / need to enhance that interface during the runtime. [e.g. for the a theoretical EntityWorkspaceStatusInterface, which has isInitialPublished() / setInitialPublished() methods].

Also some things must persist in entity cache, while others are just temporary to the object.

Which is kinda what I though of with my modifiers:

$entity = new DynamicInterfaceEntity($entity);
$entity->addDynamicInterface('EntityPublishedInterface', $entity_published_interface_provider);

with the big problem that an instanceof won't work unless it is a true dynamic child entity, but if that code was changed to check for:

$entity->hasDynamicInterface('EntityPublishedInterface') it would work for both.

Brainstorming end ;).

there's existing API for that purpose
- user_data service, associates and removes additions to user entity
- third-party-settings for config entities

and less known
- key value entity storage - #2208617: Add key value entity storage