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

Question

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

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

在为此类系统实施更新机制时，有哪些最佳实践和需要考虑的事项？ 几乎所有信息都与打包和分发阶段有关——签名等，但我更关心更新过程本身。

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

1. 该机制应如何处理具有某些副作用或先决条件的代码更新？例如，用户配置文件的架构已更改 - 因此应将以前的配置转换为新配置（我想它应该对用户透明）。显然，这仅在从版本 X 更新到 Y 时完成，而不是在全新安装时完成（可以分配默认值）。

   应该如何处理，特别是如果我们有版本差距？- 比如客户端版本是1，最新的是4，需要从2到3转换。应该是一个累积更新，会保存所有更新（1->2->3->4）并处理这一切都与脚本？或者每个更新都应该独立存在，客户端应该运行一系列更新？

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

标签： pythondesign-patternsupdates

Answer 1

好吧，你需要的是一个图表。是的，数据结构。我敢打赌你的图表将是有向的和无环的 - DAG。如果没有，你很可能遇到了麻烦。

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