Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-08-06 17:36:53 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
bcquality/microsoft/knowledge/breaking-changes/obsolete-table-fields-instead-of-deleting-them.md
Jesper Schulz-Wedde 26f7cb72a8 Clarify published field identity rules 
State explicitly that a published field keeps its ID, name, and type while a replacement is added as a separate field under an unused ID.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 9825b012-e653-496a-9310-c1f4b6f8ac27
2026-07-15 09:29:18 +02:00

2 KiB
Raw Blame History

bc-version domain keywords technologies countries application-area
all
breaking-changes
table-field
obsoletestate
obsoletereason
obsoletetag
pending
removed
data-loss
al
w1
all

Obsolete published table fields instead of deleting, renaming, or renumbering them

Description

A shipped table field carries both a source-level contract and persisted data. Renaming a field while retaining its ID is prohibited by AppSourceCop AS0005 and can break dependent extensions, but it is not inherently a drop-and-readd operation and should not be described as automatic data loss. Deleting the field or replacing it under a different ID is the data-loss risk: the old field storage is no longer represented unless data is migrated. The supported path is to keep the old field and obsolete it, add a replacement under a new ID, and migrate values before later removal.

Best Practice

Keep the old field's ID, name, and type unchanged. Add the replacement as a separate field under an unused ID, then mark the old field ObsoleteState = Pending with an ObsoleteReason that names the replacement and an ObsoleteTag recording the obsoletion version. Keep the old field readable so an upgrade codeunit can copy its data during the deprecation window. Move it to ObsoleteState = Removed only in a later release, after the window has passed and data has migrated.

See sample: obsolete-table-fields-instead-of-deleting-them.good.al.

Anti Pattern

Renaming published Email to Contact Email with the same ID violates the compatibility contract and AS0005, even though the retained ID does not itself imply a fresh empty column. Deleting Email or changing its ID additionally risks losing its stored values. Detection: any previously shipped field whose name changes at the same ID, or whose original ID disappears without the unchanged field being retained as Pending and its data migrated to a separate replacement field.

See sample: obsolete-table-fields-instead-of-deleting-them.bad.al.