由于更新业务网络可能会破坏您的API并且您可能无法获取旧数据。我们正在寻找关于在更新业务网络和使用composer进行部署之前应该注意什么的通用指南。
答案 0 :(得分：1)
我们会将此内容纳入下周发布的文档中......
预计作曲家模型会随着时间的推移而变化和发展。但是，在进行模型更改时必须应用一些注意和纪律，以确保现有实例对于新模型仍然有效。
模特M＆＃39;如果使用模型M创建的实例对于模型M＆＃39;有效，则与模型M 兼容。如果实例有效，则可以使用Serializer反序列化它们。
本文档中使用了以下术语：
model类型string的属性。一个类（资产SampleAsset）：
``` 命名空间org.acme.sample
assetId标识的资产SampleAsset { o String assetId - ＆GT; SampleParticipant所有者 o字符串值 } ```
班级的一个实例：
{
"$class": "org.acme.sample.SampleAsset",
"assetId": "assetId:6463",
"owner": "resource:org.acme.sample.SampleParticipant#participantId:8091",
"value": "secret plant frequently ruler"
}
可以在命名空间中添加新类，而不会破坏与预先存在的实例的兼容性。
本节描述了对类的声明及其属性的更改对预先存在的实例的影响。
重命名一个类将破坏与该类的任何预先存在的实例或与该类的关系的兼容性。
如果未将声明为abstract的类更改为声明为abstract，则尝试创建该类的新实例将在运行时抛出错误;因此，不建议对广泛分布的类进行此类更改。
将声明为abstract的类更改为不再声明为abstract，不会破坏与预先存在的实例的兼容性。
如果一个类本身就是一个超类，那么在加载时抛出一个错误。对于广泛分布的类，不建议在加载实例时导致类层次结构的更改。
更改类类型的直接超类不会破坏与预先存在的实例的兼容性，前提是类类型的超类总数不会丢失属性。
如果对直接超类的更改导致任何类不再分别成为超类，则如果预先存在的实例与修改后的类具有关系，则可能会导致错误。对于广泛分布的课程，不建议进行此类更改。
如果属性声明为optional或被赋予default值，则向类添加属性不会导致与预先存在的实例不兼容。添加既不是可选的也不具有默认值的新属性将破坏与该类的任何预先存在的实例的兼容性。
更改属性的基数（将数组[]更改为非数组或反之亦然）将破坏与该类的任何预先存在的实例的兼容性。
从类中删除属性将破坏与引用此字段的任何预先存在的实例的兼容性。
如果属性由预先存在的实例使用，则更改属性的类型可能会导致错误。
如果预先存在的实例使用该属性，则更改属性的验证表达式可能会导致错误。
关系属性遵循与其他类型相同的规则。
在枚举类型中添加或重新排序常量不会破坏与预先存在的实例的兼容性。
如果预先存在的实例尝试访问不再存在的枚举常量，则会发生错误。因此，不建议对广泛分发的枚举进行此类更改。
在所有其他方面，枚举的模型演变规则与类的规则相同。