如何保持产品元数据在项目中的兼容性

Sailing

总体思路

主要有两种思路:

1. 基于Json节点变更记录的方法. 以产品的元数据作为基线, 项目中记录对元数据的变更. 这种方法的问题时, 当基线变更时, 如何判断对应的变更记录是否还适用? 这些变更记录是否还符合语义?

2. 基于元数据语义schema的变更控制. 对元数据中每个元素分别定义其在项目的变更行为. 对于固定schema的元数据, 此方法理论上可行; 对无固定schema(主要是无限嵌套层次结构)的元数据, 此方法不可行, 一个变动的办法是此类元数据分拆或者重整, 忽略含有层次结构的部分.

相比之下, 方案1形式上更加general, 但不确定是否满足语义; 方案2更加special, 但粗看比较可行, 但局部还是要用到方案1中的方法来管理变更.

Json节点变更记录

先分析一下json节点变更记录的形式

基于元数据语义schema的变更控制

首要的问题的问题是重整无固定schema元数据. 目前存在无固定schema的元数据有:
- entity 层次结构的实体字段
- ui 层级结构的布局
- initializer 层次结构的scope, 和目标实体类型一致
- validator

实际需求

单据

场景

• 表单菜单项别名在项目中调整了, 产品更新后, 希望保留别名.
• 单据列表: 项目中调整了通用列表, 例如增加列, 调换顺序, 调整宽度, 调整锁定等. 产品更新后, 希望保留项目调整. 整个单据列表作为一个整体
• 项目中增加了调整了通用验证, 产品更新后, 还是使用调整后的通用验证.
• 列表或详情动作按钮
  
  • 项目中增加了项目, 产品更新后, 希望保留.
  • 项目中调整了项目的配置, 产品更新后, 改动的配置项希望保留.
  • 项目中删除了项目, 产品更新后, 希望还是保持删除状态.
  • 产品中新增了项目, 希望项目中也反映出来.
  • 产品中删除的项目, 希望项目中保留.
• 附加列表
  
  • 项目中增加了一个附加列表, 产品更新后, 希望保留.
  • 项目中调整了附加列表的选项, 希望保留.
  • 项目中调整了附加列表的列表视图, 希望整体保留.
  • 产品中新增了附加列表, 希望项目中也反映出来.
  • 产品中删除了附加列表, 项目中没有改动, 也直接去掉.

调整策略

• 关联实体, 主业务组织类型, 不允许修改
• 其他一级字段允许修改
• 对需要按照集合管理的
  
  • 项目中新增的, 保持新增;
  • 项目中修改的, 按照项目中来;
  • 项目中删除的, 保持删除;
  • 产品中新增的, 应用新增;
  • 产品中修改的, 如果项目中没有改, 则按照产品, 否则按照项目.
  • 产品中删除的, 如果项目中没有改, 则删除, 否则按照项目.
• 列表或详情动作按钮列表, 按集合策略管理.
• 附加列表, 按集合策略管理.

UI

场景

• 产品有标准表单布局, 项目中可以调整布局.
• 产品新版本调整了布局, 项目中已经调整过的布局, 保持项目调整不变;
  
  • 没调整过的需支持两种模式: 1. 更新新产品更新, 2. 保持老布局不变.
• 项目中布局微调, 修改了一个禁用项目, 新产品布局调整后, 期望应用新布局, 并还是禁用哪个项目?

调整策略

• 布局是允许在系统中调整的. 任何对布局的微调都算作对布局发生了调整.
• 什么是布局调整, 什么组件定义调整, 这一点需要谨慎设计.
• 需要事先(或者在产品更新时?)确定是否需要应用新产品更新.

验证器

场景

• 产品有一套标准验证规则, 新项目中可以禁用标准规则, 但不能改动标准规则, 也可以新增其他规则.
• 产品新版本中调整了标准验证规则, 并新增了几条. 原项目已禁用部分继续禁用, 新增部分新增.

调整策略

• 项目上可以禁用项目中的标准规则, 但不允许改动和删除, 另外允许添加规则
  上述原则的隐含条件是每条规则都有一个产生之后就恒定不变的id

实体

场景

• 项目中新增了字段, 产品更新后, 希望保留该字段.
• 项目中删除了字段, 产品更新后, 希望保持删除.
• 项目中修改了字段类型, 产品更新后, 希望保留变更??
• 产品中新增的字段, 产品更新后, 也希望新增

调整策略

• 因为实体是硬编码的, 产品和项目变更协调主要取决于版本控制工具和文件比较合并工具. 实际上目前还没有很好的管理办法. 等到实体也能通过json元数据软定义的时候, 讨论实体的产品和项目协调才有意义.

单据类型

场景

- 基本信息修改

项目修改变更记录在基线变动情况下的兼容性

形式案例

• a
• b{}
  
  • b1
  • b2{}
    
    • b21
  • b3[]
    
    • b31
• c[]
  
  • c1
  • c2{}
    
    • c21
  • c3[]
    
    • c31

字段在项目中改了, 产品中也改了

字段A, 产品原始值A1, 项目改成了A2, 产品中升级成A3.
如果这个字段原本设成不允许修改, 那么不存在这种情况, 即便存在, 也变成A3, 且清除修改记录?
原本设为可以修改, 现在也是可以修改, 那么升级后保持A2;
原本设为可以修改, 现在设为不允许修改, 那么变为A3.

字段在项目中改了, 产品中废弃, 甚至取消了

原产品字段a, 产品原始值A1, 项目中改成了A2, 产品schema中作废.
这种情况一般伴随着功能优化升级, 会搭配元数据迁移.
最后的效果项目体现出来, a字段作废, 原A字段修改内容调整成对AZ字段的修改.

新产品新加字段

原产品中没有, 新产品新加了D.
最后的效果就是项目中也增加了D.

子对象中字段类似上述三例操作

也同上三例

子对象中的字段在项目中改了, 产品中整个子对象删除了.

是否可修改的配置情况如下:

这种情况往往涉及字段变更, 起码涉及UI调整. 一般来说, 调整后的结构包含了原功能, 但配置的地方有调整, 此时需要配合元数据迁移; 如果配置的地方改到runtime了, 需要提供调整指南(避免这样做).

总之, 产品中字段schema取消了, 那么

产品中整个子对象为空, 项目中增加了, 新产品中也增加了, 子对象节点设置了