Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
This is a followup of #2810381: Add generic status field to ContentEntityBase where the status field is now introduced in CEB and there is an update function to update the field storage definition comment_update_8300 which however is retrieving the old cached definition and is passing it directly to EntityDefinitionUpdateManager::updateFieldStorageDefinition without making the needed changes on it.
Proposed resolution
Make the needed changes on the cached field storage definition before passing it to EntityDefinitionUpdateManager::updateFieldStorageDefinition.
Remaining tasks
None.
User interface changes
None.
API changes
None.
Data model changes
None.
Comment | File | Size | Author |
---|---|---|---|
#19 | 2841614-19.patch | 974 bytes | amateescu |
#18 | 2841614-18.patch | 591 bytes | prash_98 |
#5 | interdiff-3-5.txt | 1 KB | hchonov |
#5 | 2841614-5.patch | 974 bytes | hchonov |
| |||
#3 | 2841614-3.patch | 668 bytes | hchonov |
Comments
Comment #2
timmillwoodComment #3
hchonovComment #4
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedWe need to get the field storage definition from the entity definition update manager :)
Comment #5
hchonovComment #6
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedLooks great now!
Comment #7
alexpottObviously missing test coverage then.
Comment #9
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedI don't see how this could be tested. The current update function uses the latest definition of the 'status' field from code, so something can fail only when that field definition is changed again.
Comment #10
catchI'd think we could test this by introspecting the database schema after the update?
Comment #11
catchAlso bumping this to critical - doesn't it mean a site gets stuck with pending schema update warnings?
Comment #12
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedNo, the update is performed correctly, the only problem is that the "initial state" of the field definition is taken from the wrong place. An analogy to D7 would be something like: don't call hook_schema() in an update function to get the schema for creating a table, but hardcode the new table schema instead :)
Comment #13
hchonovBut after the update has ran there will be still pending updates, right? I am pretty sure that
drush entity-updates
will return an inconsistency and that the status field has to be updated.Comment #14
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@hchonov nope :) If that were the case, our existing update path tests would show the problem immediately.
Comment #15
hchonov@amateescu do our update tests do the same like
drush entity-update
and check for inconsistencies between the cached field definitions the ones defined in the Entity::baseFieldDefinitions?Comment #16
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@hchonov, exactly: http://cgit.drupalcode.org/drupal/tree/core/modules/system/src/Tests/Upd...
Comment #18
prash_98 CreditAttribution: prash_98 commentedPlease review the changes...
Comment #19
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@prash_98, I don't understand that patch at all.
Re-uploading #5, which is the one that is ready for commit.
Comment #20
alexpott@amateescu but @catch's and @hchonov's concerns are still valid - ie. is there any way that we can have a test that fails if we make the same mistake in the future?
Comment #21
alexpottComment #23
catchI've opened a follow-up here #2850076: Write test coverage to demonstrate why schema definitions should not be got from code in updates.
Committed/pushed to 8.4.x and cherry-picked to 8.3.x. Thanks!