Active
Project:
Drupal core
Version:
main
Component:
entity system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
16 Apr 2019 at 10:07 UTC
Updated:
19 Jun 2020 at 10:08 UTC
Jump to comment: Most recent
The current approach of using a single entity type definition has some of the following issues:
EntityDefinitionUpdateManager. Some features of entity types "just work" after a cache clear, some don't.entity_type.manager which definition I should be making decisions based on in custom code.Having an entity type definition persisted to the database, that for non-storage related tasks is never actually invoked, but may perhaps be invoked in the future depending on the needs of $subsystem doesn't seem ideal. Especially since there is no warning in ent-up or the status report based on mismatched keys that don't inform storage. Is it assumed that installed definitions become out of sync with code definitions?
Split entity type definitions into two distinct objects (or sections within the current object, with clear boundaries) responsible for:
EntityLastInstalledSchemaRepository.
Comments
Comment #2
hchonovWhile I understand the frustration, I also think that it is safer to always write an update. It is also easier to always have an update, event it has no effect instead of having to think about the use cases when an update is required and when not.
Comment #3
sam152 commentedUnder the proposed solution, you would only write an update for changes to the 'storage' plugin definition. This is similar DX to field definition/storages. The result would mean writing less update hooks, which is a positive thing IMO.
I don't think users have are any expectations that an update hook needs to be written when updating non-storage related keys. Not even core is following this standard. Here is an example of an annotation change committed with no associated update hook: #2669802: Add a content entity form which allows to set revisions . Now there is a discrepancy between the "installed" definition and the live definition.
Reconciling or catching these kinds of issues in code reviews seems pretty difficult.
On the flip-side, if this is the right approach for post 8.7 entity annotation changes...
Then something should test any definition changes are always reflected by update hooks and these should also bubble up to users in the form of warnings on the status page etc. I don't think anything does that right now.
Comment #4
sam152 commentedHere is another example: #3054582: Add field ui to workspaces.
Should these annotation changes have an update hook?
Comment #7
alexpott+1 to this. We hit this with field_encrypt - see #3153125: Cache issue persists after update to 8.x-2.0-alpha2
The current docs for for hook_entity_type_alter() feel very insufficient...
In 8.7.0 the
changed quite drastically. There are now many situations where this does not work. I'm not sure even the example in the hook works now.
Comment #8
amateescu commentedIt doesn't, you need to update the last installed definition and set the new storage class there as well :/