EventSourcingDB 1.3.0 可用

这篇文章将介绍升级时发生的变化以及需要注意的事项。 v1 API 的支持截止日期为 2027 年 1 月 31 日，后续版本将删除它，因此您可以按照自己的节奏迁移到新版本。从今天开始，EventSourcingDB 的文档将位于 eventfoundation.io 上；每个旧链接都通向那里。经久耐用的新 API # 新的 v2 API 与 v1 API 一起运行，使用相同的数据。它的中心思想很简单：一旦服务器接受了请求，它的结果就在 body 中。当请求经过身份验证、其正文具有其路由期望的形状并且保持在其限制范围内时，该请求即被视为已接受。不成立的前提条件、未知的事件类型、只读模式的数据库——所有这些都作为客户端可以读取的答案返回，而不是作为客户端必须解释的状态代码。每个错误都带有一个代码，该代码是指向其自身页面的链接，该代码解释了错误发生的原因以及如何修复它。您将在 Errors 下找到它们。结束的流式答案（例如阅读事件）以明确的结束项结束，因此客户可以从被中断的答案中分辨出完整的答案。当流等待时，服务器通过它发送心跳，这可以防止代理在中间关闭它。 v2 API 还带来了递归前提条件： isSubjectPristine 、 isSubjectPopulated 和 isSubjectOnEventId 现在可以应用于一个主题及其下面的每个主题。当决策取决于树的整个部分而不是单个主题时，这很有用。所有八个客户端 SDK 的当前版本均使用这两种 API，并在服务器提供的任何地方使用 v2 API。因此，除了更新 SDK 之外，您不必更改代码，只要数据库前面的代理允许通过 HTTP 方法 QUERY 即可，v2 API 使用该方法进行读取。如果您直接调用 HTTP API，迁移到 v2 会逐条显示发生的变化。移动和备份数据 # 导出和导入可以更轻松地将事件移动到新数据库中。两者每行都使用一个普通的 CloudEvent，包括其 ID 和时间，因此导出导入无需任何转换。由于导入本身会计算哈希值，因此您还可以导出历史记录，从中删除个人数据，然后导入结果，而无需手动计算任何哈希值。增量备份仅保留自上次备份以来写入的事件。恢复会先进行完整备份，然后进行增量备份，这样可以保持大型数据库的定期备份较小。恢复自身也变得相当快，因为​​它现在批量写入事件。在负载下更快、更坚固 # 无论对于一个客户端还是对于多个客户端来说，写入速度都快得多，并且不会随着商店的增长而减慢。运行 EventQL 查询也相当快，尤其是对于读取许多事件、分组、排序或连接多个源的查询，读取事件也是如此。索引占用的文件要少得多，因此在大型数据库中读取主题的事件会变得更快，并且验证存储的完整性会报告它发现的每个不一致之处，最多可达一百个，而不仅仅是第一个。 1.3 中的许多其他工作在您需要之前是不可见的。每个请求、每个答案和每个空闲连接都有时间限制，因此缓慢或卡住的客户端无法再永远保留资源。 EventQL 查询对嵌套深度和占用内存量有限制，这可以防止单个查询溢出堆栈或占用尽可能多的内存。服务器在恒定时间内比较 API 令牌，并拒绝从可以猜测的令牌开始。如果它无法存储写入，例如因为磁盘已满，它将切换到只读模式，直到重新启动，继续提供读取服务，通过其运行状况端点报告此情况，并在日志中指出原因。限制列出了界限。在生产中运行 # 一些添加旨在在生产中运行 EventSourcingDB。默认情况下启用速率限制，并根据计算机的大小进行缩放，因此发送过多请求的单个客户端不会压垮数据库。 v2 API 的运行状况端点使用 OpenMetrics ，这意味着您可以直接使用 Prometheus 和类似工具来抓取它，并且它会报告有关该进程的更多信息，例如其内存和文件描述符；日志记录和监控列出了它报告的内容。如果您想确保只写入已知的事件类型，则新标志 --require-event-schemas 会拒绝写入和恢复其类型没有注册架构的事件。默认情况下它是关闭的。 /.well-known/api-catalog 处的 API 目录将工具指向两个 API 的 OpenAPI 文档。升级之前# 此版本要求升级时务必小心。开始之前请阅读升级EventSourcingDB；以下是最重要的几点： 首先备份数据。 1.3版本打开的数据目录无法再次被早期版本打开，因此备份是恢复的唯一方法。停止旧服务器b