数据一直在改变 - 这首先要拥有数据库！不仅是内容变化，而且是数据的形状。
我花费大量时间思考数据的变更管理 - 如何使用批准工作流程进行更改请求，使用户可以更新其内容，并在将其数据投入生产之前，在实践中了解如何。
但是，数据生命周期的一部分是将这些更改管理到数据模型本身。
图形数据库中的模式迁移
在普通的RDBMS中，可以执行一种模式操作的命令语言。您可以添加或删除表，添加或删除外键，然后从表中添加或删除列。
在图数据库中需要类似的内容，您需要在图中添加和删除边缘，删除节点类型，添加新节点类型和更改键。
但是，当涉及分支机构和合并的变更管理时，事情变得更加棘手。为了使事情顺利进行，我们需要跟踪我们如何到达自己的位置。
架构迁移为一流公民
在最新版本的terminusdb中，我们在每个提交中添加了架构迁移的跟踪。该模式迁移信息可用于确保可以使分支相提并论，以便我们可以在它们之间进行更改。
此外，这将允许我们拥有模型产品，这些产品可以以模型产品的下游用户可以跟踪模式更改的方式进行更新，而无需弄清楚如何更改其数据。
削弱和增强模式
我们可以将模式的种类分为两种类型：削弱和增强。
弱化的操作是向后兼容的。它以一种无法使已经存在的数据无效，并且不需要对现有数据进行任何更改的方式更改模式。
在SQL世界中，这可能是添加新表格，或在表中添加无效的列。
在terminusdb中，这是指在类中添加可选或设置属性的操作，或添加新类，或扩展具有新值的枚举。
关于这些操作的另一个有趣的观点是可以推断操作。我们可以从添加新的架构文档或更新模式文档的更新中猜测它是一个弱化的操作，这意味着您不必明确迁移模式，但只能直接编辑模式。
弱点
那么我们如何推断模式迁移？让我们用命令行工具演示。
terminusdb db create admin/m
echo '{ "@type" : "Class", "@id" : "A", "a": "xsd:string" }' | ./terminusdb doc insert admin/m -g schema
我们创建了一个新的数据库（称为M），并在模式中添加了一种类型的A类。
如果我们查看此日志（带有详细标志），我们可以看到推断的迁移报告。
terminusdb log admin/m -v
您会按照以下方式获得一些东西：
wrhzet2rzenaiud9dc7nw03gbgwfsof
--------------------------------
Date: 2023-04-21T11:24:49+00:00
Author: admin
Message: cli: document insert
Migration:
[
{
"@type":"CreateClass",
"class_document": {"@id":"A", "@type":"Class", "a":"xsd:string"}
}
]
已经推断出获得此模式的迁移操作。
此外，我们可以使模式的更改更加复杂，该模式也很弱，例如：
echo '{ "@type" : "Class", "@id" : "A", "a" : "xsd:string", "b" : { "@type" : "Optional", "@class" : "xsd:boolean" }}' | terminusdb doc replace admin/m -g schema
最新提交是从命令中给出的：
terminusdb log admin/m -v -c 1
现在将沿着：
的线条
cezsjyywg7o1r2f1fj6otvod5ka6zqa
--------------------------------
Date: 2023-04-21T11:26:35+00:00
Author: admin
Message: cli: document replace
Migration:
[
{
"@type":"CreateClassProperty",
"class":"A",
"property":"b",
"type": {"@class":"xsd:boolean", "@type":"Optional"}
}
]
此迁移操作告诉系统我们以较弱的操作更新了类A类。
加强操作也可能隐含地使用推理，但由于它仍然是实验性的（它可能会更改您的实例数据！）
，我们尚未公开此功能！显式迁移
也可以通过明确说明通过API或通过CLI进行明确的迁移，无论是加强还是弱。
首先，让我们添加一些数据以说明。
echo '{ "a" : "foo", "b": true }' | terminusdb doc insert admin/m
这是合法的，因为我们的上述更改引入了B财产。
现在，要在整个整数中添加新的必需属性C，我们可以编写以下内容：
terminusdb migration admin/m --operations '[{"@type" : "CreateClassProperty", "class" : "A", "property" : "c", "type" : "xsd:integer", "default" : 0 }]'
此返回：
{"instance_operations":1, "schema_operations":1}
这意味着我们更改了数据库中的数据。
要看到这一点，我们可以将文档撤回：
terminusdb doc get admin/m
返回：
{"@id":"A/86b5201b5e907ad916ed650b7656828a8f89bea12edf50ecfd341cd290194695","@type":"A","a":"foo","b":true,"c":"0"}
以0的新默认值为0（不幸的是，它是字符串，因为它实际上是一个无限的整数，它会导致许多编程语言的问题，如果不表示为字符串）。
针对迁移
这本身就非常好，因为即使我们拥有实例数据，我们也可以迁移数据的形状，但是在执行更改式型工作流程时尤其重要。
。例如，如果我立即分支数据库（用主的隐式基础分支）：
terminusdb branch create admin/m/local/branch/other
我现在可以再次更新主分支：
echo '{ "@type" : "Class", "@id" : "B", "b": "xsd:string" }' | ./terminusdb doc insert admin/m -g schema
现在，我的另一个分支与主分支相比很困难，因为模式不是对称的。
为了减轻这个问题，我可以通过书面形式以主要针对分支机构的架构：
terminusdb migration admin/m/local/branch/other -t admin/m
现在，如果我查看模式，我会发现它已成为对称的，包括在必需的属性上添加默认值！
terminusdb doc get admin/m/local/branch/other
返回：
{"@id":"A/86b5201b5e907ad916ed650b7656828a8f89bea12edf50ecfd341cd290194695","@type":"A","a":"foo","b":true,"c":"0"}
结论
当然，这要求我们整个过程都有迁移，因此我们将添加一种模式，该模式迫使所有模式更新（通过文档接口或其他方式）具有有效的迁移或抛出错误。<<<<<<<<<<<<< /p>
和用于将作为其他数据产品的模型组件进口的模型产品，也应需要。
但是，如果您继续明确迁移用于模式更改或限制削弱操作，则应始终能够与您一起移动分支机构。
希望您喜欢新发现的型号灵活性！