EventSourcingDB 1.3.0：更快更稳，新API上线
EventSourcingDB 1.3.0 Is Available
EventSourcingDB 1.3.0 正式发布，带来显著的性能提升和稳定性增强。这次更新不仅让写入和 EventQL 查询速度大幅加快，还引入了全新的 v2 API，确保每个请求的结果都清晰可见，错误信息附带详细修复指南。数据迁移和备份功能更加便捷，支持增量备份和无需转换的导入导出。此外，新版本在生产环境下的表现更加稳健，默认启用限流，支持 OpenMetrics 监控，并强化了安全机制。对于正在使用的用户，升级前需备份数据并注意 API token 长度等细节；对于新用户，现在正是体验这款专为事件溯源设计的数据库的绝佳时机。
一旦服务器接受了请求，其结果就会出现在响应体中。
- bythreads
我从未在 IT 运维环境中遇到过开发者技能高到足以使用 EventSourcing 的情况——这东西理论上很完美，也适合那些极客（neckbeards），但初级开发者根本写不出能与之匹配的代码。
- zbentley
EventQL 看起来不错，但
> 在评估 EventQL 前置条件时，所有其他写入操作都会等待，以确保没有数据穿插其中；与此同时读取操作照常进行。为了防止写入操作长时间阻塞其他操作，EventQL 会将写入操作的前置条件评估时间限制在最多五秒内（从该写入操作获得执行权时开始计算，所有条件合计）：若前置条件耗时超过此限，该写入将被拒绝，不写入任何数据，并返回 400 错误。
（来自 https://www.eventfoundation.io/docs/eventsourcingdb/precondi...）
这看起来是个巨大的“脚枪”（foot gun，指容易误用的危险设计）。当然，你确实不需要实现事务语义，也不必操心一致性、MVCC 或快照问题。但代价是“每个 UPDATE ... WHERE 语句都可能让其他所有写入操作最多等待 5 秒”？真的吗？
这看起来是个糟糕的权衡，不如以下三种方案：（投入巨大精力）实现真正的事务性；（中等投入，但会显著破坏兼容性）移除对层级嵌套主体的支持，从而解除或高效地将 UPDATE-WHERE 的全局互斥限制作用域缩小到单个主体；（最低投入）直接移除对 EventQL 前置条件的支持。在任何足够大或多开发者的系统中，我怀疑“别用 EventQL 前置条件”这种建议根本行不通。
照目前的情况看，让主 EventSourcing 系统因某个客户端缓慢的 EventQL 前置条件而最多阻塞 5 秒，无异于主动招致突如其来的广泛停机事件。
话说回来，我可能忽略了某些能缓解此问题的细节……
- chaostheory
这在个人智能体场景中或许很有用，比如你想在单台机器上存储某个人一生的记忆或“想法”，以防止漂移或幻觉……但授权许可让这种用途变得不可行。