最近在做 SAP Fiori Elements 对象页时，一个很容易被忽略的问题会突然冒出来。员工记录已经进入编辑态，页面顶部也明确显示当前对象处于 Draft 状态，可沿着_manager关联读取负责人信息时，拿到的却仍然是 Active 版本。员工草稿里刚刚改过经理编号，关联区域展示的姓名却来自旧数据，保存前后的画面甚至可能不一致。前端看起来像是绑定刷新失败，OData 请求也没有明显报错，真正的断点却藏在 CDS 关联是否具备 Draft 能力这一层。SAP 对 Draft-Enabled Association 的定义很直接。关联从 Active 源实例出发时，应当落到 Active 目标实例，从 Draft 源实例出发时，应当落到 Draft 目标实例。没有启用 Draft 的普通关联，无论源实例是不是草稿，都会继续读取目标实体的 Active 数据。于是，页面能不能稳定地保持同一事务状态，并不只取决于根实体有没有draftEnabled，关联路径本身也要知道该去活动表还是草稿表。在组合关系里，这件事往往不显眼。销售订单到行项目、行项目到计划行、子节点回到父节点，这些 Composition 语义较强的关联通常能够自动获得 Draft 能力。可是，员工到经理这样的自关联并不是 Composition Child，也不是 Composition Parent。两个员工实例虽然属于同一个业务对象类型，却可能属于不同的根实例，所以框架不会默认把这条路径当成同一棵组合树内部的导航。SAP 官方模型也把这类关联列入需要显式补充 Draft 注解的场景。Draft 状态不能只停留在根节点我们今天处
最近在做 SAP Fiori Elements 对象页时，一个很容易被忽略的问题会突然冒出来。员工记录已经进入编辑态，页面顶部也明确显示当前对象处于 Draft 状态，可沿着_manager关联读取负责人信息时，拿到的却仍然是 Active 版本。员工草稿里刚刚改过经理编号，关联区域展示的姓名却来自旧数据，保存前后的画面甚至可能不一致。前端看起来像是绑定刷新失败，OData 请求也没有明显报错，真正的断点却藏在 CDS 关联是否具备 Draft 能力这一层。SAP 对 Draft-Enabled Association 的定义很直接。关联从 Active 源实例出发时，应当落到 Active 目标实例，从 Draft 源实例出发时，应当落到 Draft 目标实例。没有启用 Draft 的普通关联，无论源实例是不是草稿，都会继续读取目标实体的 Active 数据。于是，页面能不能稳定地保持同一事务状态，并不只取决于根实体有没有draftEnabled，关联路径本身也要知道该去活动表还是草稿表。在组合关系里，这件事往往不显眼。销售订单到行项目、行项目到计划行、子节点回到父节点，这些 Composition 语义较强的关联通常能够自动获得 Draft 能力。可是，员工到经理这样的自关联并不是 Composition Child，也不是 Composition Parent。两个员工实例虽然属于同一个业务对象类型，却可能属于不同的根实例，所以框架不会默认把这条路径当成同一棵组合树内部的导航。SAP 官方模型也把这类关联列入需要显式补充 Draft 注解的场景。Draft 状态不能只停留在根节点我们今天处
