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.
Followup from #1969698: ConfigEntity::save() should disallow saving ID/UUID conflicts (Field UUID changes can badly corrupt field data), postponed on discussion in #1969800: Add UUIDs to default configuration.
We're adding this exception handling to both Field
and FieldInstance
. Should ConfigEntity
(or even entity) enforce that the UUID cannot change for an existing entity?
Comments
Comment #1
xjmComment #2
xjmSee also: #1609418: Configuration objects are not unique.
Comment #3
swentel CreditAttribution: swentel commentedAlso related #1740378: Implement renames in the import cycle (but more or less duplicate) - and a big problem for fields at the moment (unless we start dropping features), see this comment http://drupal.org/node/1740378#comment-7130190
Comment #4
tstoecklerThis makes total sense. I see no reason why this should be specific to ConfigEntities. Adjusting title for that.
Comment #5
xjmSee also: #2041887: check that id does not exist before saving a new ConfigEntity
Comment #6
sunLooks like the deps are resolved.
Comment #7
tim.plunkettConfigEntityBase::preSave() has partial handling for this.
Comment #10
tim.plunkettNot actively part of the Blocks-Layouts work.