Repository navigation
Make MetaDataProtoEditor always rename the canonically named union field - #4731
Open
robert-brunel wants to merge 1 commit into
Open
robert-brunel wants to merge 1 commit into
robert-brunel wants to merge 1 commit into
Conversation
robert-brunel
force-pushed
the
apple/robert-brunel/renameRecordTypes-6
branch
from
October 9, 2026 18:47
6333e4e to
6e1907c
Compare
robert-brunel
force-pushed
the
apple/robert-brunel/renameRecordTypes-6
branch
from
November 3, 2026 13:10
6e1907c to
8a7cc09
Compare
robert-brunel
force-pushed
the
apple/robert-brunel/renameRecordTypes-6
branch
2 times, most recently
from
November 9, 2026 13:29
2883cd5 to
f56806c
Compare
robert-brunel
force-pushed
the
apple/robert-brunel/renameRecordTypes-6
branch
2 times, most recently
from
November 9, 2026 14:37
9d190d8 to
7fca050
Compare
robert-brunel
force-pushed
the
apple/robert-brunel/renameRecordTypes-6
branch
2 times, most recently
from
November 9, 2026 15:31
9b3c4fb to
0d189bc
Compare
robert-brunel
marked this pull request as ready for review
November 9, 2026 15:32
…field When several union fields reference a renamed record type, `renameRecordType()` and `renameRecordTypes()` now always rename the one that is canonically named. Previously, a field with a higher number could “displace” it, which would result in the canonical field keeping its old name. This could also cause a batch rename that swaps two type names to be spuriously rejected with “Cannot rename union field because a field of the new name already exists”. `RecordMetaDataBuilder` writes the records of a type under its canonically named union field if there is one, and otherwise under the one with the highest number. So the old behavior also effectively moved the records of the renamed type to the higher-numbered field. With this change, the editor now selects the union field by the same rule as `RecordMetaDataBuilder`, so that records keep getting written under the original field. Follow-up to #4536. Resolves #4732.
robert-brunel
force-pushed
the
apple/robert-brunel/renameRecordTypes-6
branch
from
November 9, 2026 15:37
0d189bc to
f051ae2
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When several union fields reference a renamed record type,
renameRecordType()andrenameRecordTypes()now always rename the one that is canonically named. Previously, a field with a higher number could “displace” it, which would result in the canonical field keeping its old name. This could also cause a batch rename that swaps two type names to be spuriously rejected with “Cannot rename union field because a field of the new name already exists”.RecordMetaDataBuilderwrites the records of a type under its canonically named union field if there is one, and otherwise under the one with the highest number. So the old behavior also effectively moved the records of the renamed type to the higher-numbered field. With this change, the editor now selects the union field by the same rule asRecordMetaDataBuilder, so that records keep getting written under the original field.Follow-up to #4536. Resolves #4732.