The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
In #1916790: Convert translation metadata into regular entity fields we added automatic notification of field storage definition creation to avoid forcing users to run updates before being able to translate content:
[The committed] patch makes the UX of enabling translation on an entity type for the first time slightly worse as updates need to be run before things actually work. I think we should add a method on the definition update manager to apply changes only pertaining a single provider (module). This would allow CT to update the schema automatically. I think this particular case does not need a manual confirmation by the user, unless a huge number of entity is already existing, which could make adding columns a very long operation.
The code added over there could be generalized and add onto the definition update manager, so other modules with similar use cases can leverage it. We also need to figure out how to deal with potentially long schema updates.
Proposed resolution
- Add a method to the definition update manager to apply updates only for a specific provider.
- Add a method to the entity manager to mark one or more entity/field storage definition as up-to-date, that is telling the system no more updates are required. This should cover especially changes to the field storage definition schema.
Remaining tasks
- Solution definition
- Implementation
- Reviews
User interface changes
None
API changes
None, just additions
| Comment | File | Size | Author |
|---|---|---|---|
| #31 | 2346013-nr-bot.txt | 159 bytes | needs-review-queue-bot |
| #14 | storage-definition-updates-2346013-14.patch | 2.57 KB | jhedstrom |
| #8 | 247d551214.txt | 2.6 KB | dawehner |
Comments
Comment #1
plachOne more tag
Comment #2
plachComment #3
plachBetter title
Comment #4
plachComment #5
plachComment #6
plach#1916790: Convert translation metadata into regular entity fields has been committed (yay!)
Comment #7
legolasboThe regression mentioned in the issue summary has been filed as a bug report, sparking my interest.
In #2418563: Column not found: 1054 Unknown column 'content_translation_source' i've added a patch (including tests) to fix the regression.
Comment #8
dawehner@catch asked me to post something here.
Due to various misbehaviours we ended up with a schema of DEV but using beta 6. This resulted in update.php pointing out various updates.
Here is small script which updates the various internal states so update.php doesn't want to update any longer.
PS: A slightly related issue #2441867: Don't require settings.php to be writeable in update.php
Comment #9
plachAdded proposed solution.
Comment #10
berdirSounds good to me. For context, here's an example update function that I wrote that needed the second part (being able to mark a certain field as manually updated): https://gist.github.com/Berdir/3bfdb91e664e325004ba.
Pretty complicated, mostly because many parts are protected right now. There's no way to get at the generated schema for a certain field for example.
Comment #11
jhedstromSeeing a need for this over in #2540990: Need to update stored schema data (h2h module). Would adding a public
setSchema()be an option to work around the need for reflection?The IS mentions marking storage schema as up-to-date, but this runs into the problem of update hooks not knowing about the current state of the schema when they are run.
Comment #12
jhedstromPerhaps something along these lines.
Comment #14
jhedstromPerhaps this.
Comment #15
berdirThe point of my callback/event idea is that you don't have to worry about this. You'd be responsible for setting the schema to the target field definition/schema that you get passed in. And you just need to confirm that you updated a given field which then has the same result as if the field was automatically updated.
Comment #16
jhedstrom@berdir that makes a ton of sense, I just wasn't clear on the exact details of the callback.
So would we implement an event that modules could subscribe to, the schema would be passed along to those subscribers, and they would a) fire any database manipulation, and then b) update the passed schema to their current state?
The entity update system would then store that schema, and if it still doesn't match the latest schema, the automated update system would continue to send out events until another listener fixed the schema?
Comment #17
plach@Berdir @jhedstrom:
Your feedback in #2542748: Automatic entity updates can fail when there is existing content, leaving the site's schema in an unpredictable state would be welcome.
Comment #29
quietone commentedUpdating tag.
Comment #31
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #32
mfbThis issue seems still relevant today? I wanted to figure out how a contrib field type would go about updating its schema.