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

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

好吧，您需要一张图。是的，数据结构。我敢打赌，您的图表将被定向且非循环-DAG。如果不是这样，您很可能会遇到麻烦。

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