代码数据库应用程序更新机制的设计

Question

我有一个基于python的应用程序，它包含大量的模块 并与两个数据库交互：

1. 元数据（在某些情况下需要更新）
2. 客户端数据 此应用程序可以在没有internet访问的环境中手动部署。你知道吗

在为此类系统实施更新机制时，最佳实践和考虑事项是什么？ 几乎所有的信息都是关于打包和分发阶段-签名等，但我更关心的是更新过程本身。你知道吗

我考虑过使用pip包版本和基于版本的脚本的元数据数据库来处理代码更新。 这就提出了新的问题，如：

1. 机制应该如何处理具有某些副作用或先决条件的代码更新？例如，用户配置的模式 文件已更改-因此应该将以前的配置转换为新配置（我猜它应该对用户透明）。 显然，这只在从版本X更新到Y时完成，而不是在干净的安装（可以指定默认值）上完成。你知道吗

   应该如何处理，尤其是当我们有版本差距的时候？-例如，客户端版本是1，最新版本是4 转换的需要是从2到3。它应该是一个累积更新，将保存所有更新（1->；2->；3->；4）并处理所有这些 有剧本吗？或者每个更新都应该独立运行，客户端应该运行一系列更新？

2. 以防元数据数据库太大~GB。管理其更新的最佳方法是什么？显然不是每次都发送给客户机整个数据库-什么是计算两个版本之间的增量并只发送一个带有DML指令的脚本的最佳方法？你知道吗
3. 如何管理数据库和代码基版本之间的依赖关系？例如，如果数据库架构中的某个字段已更改 所以代码基版本也应该更新（代码版本X支持数据库版本Y）？你知道吗
4. 在这些情况下，应如何处理故障恢复？例如，在安装一系列pip包更新时 其中一个中途失败了？如何恢复到以前的状态？除了复制文件外，有没有备份当前版本的好方法？你知道吗

Answer 1

你需要的是一张图表。是的，数据结构。我打赌你的图会是有向的，非循环的。如果没有，你很可能会有麻烦。你知道吗

1. 不知道你在问什么。但没有版本差距。从未。有一个完全确定的序列：v1->；v2->；v3（哇！看起来又是一只狗，不是吗？不过，这是您将要处理的最简单的一个：只是一个常规的链表！）。一旦客户端的应用程序发现某个更新在某个地方，它就会向服务器请求更新。。从当前版本到最新版本的命令或步骤序列。它再次要求一个图表。然后它执行服务器要求的操作。你知道吗
2. 是的，计算三角洲。存储三角洲。顺便说一下，三角洲自然地表示为。。图表。GIT就是一个著名的例子，对吧？更重要的是，改变整个体系结构以适应这种需要确实是很有意义的——目前它通常被称为“事件源”：其思想是存储一个初始的——从未修改过的——状态，以及迄今为止发生在这个状态上的一系列变化。每次需要实际状态时，理想情况下使用Google的map/reduce方法。。将整个变更集简化为单个变更，这些变更通常应用于初始状态，从而生成实际状态。它非常快速，易于测试，而且相信我，对于一个庞大的系统来说非常可靠（当然，只要数据持久性机制存在，并且在通过不稳定的网络时不会丢失任何更改）。你知道吗
3. 我不认为这是一个单独的问题。这是三角洲问题的一部分。好像你在尝试建立一个相当复杂的系统。有一条规则：对于复杂的系统，没有简单的delta可以很好地工作。结论？首先，想想你的三角洲。都是关于他们的。你知道吗
4. 好吧，假设有一个状态转换version 1 -> version 2，可能有双状态转换：version 2 -> version 1。只是一个旁注：你可以得到另一个（定向）图通过“翻转”一个现有的顶点。这就是这里发生的：有一个“向前”的图形，由它产生“向后”的图形。如果你想要更多的数学方法，你需要一个group。有一种风投正是由这种想法驱动的-darcs。你知道吗