@mayli 我大概明白了，正如你说的，我也觉得应该是可以优化的[1]，或者将来可以[2]，就是可能写起来比较费劲。另外，作为抽象化的库，kLoop 我认为可以从两方面做批量优化：1 、单次主循环内批量操作：当 I/O 请求比较密集的时候，一次循环有机会批量提交处理几十上百个请求，每个请求可能都是由多个 SQE 链接实现，这样一次循环就能省几百 syscall ； 2 、提高抽象层级，直接做 HTTP 静态文件服务器[狗头]。以上还都是臆想，有待实现验证测评。

[1]: https://lwn.net/Articles/863071/
[2]: https://lwn.net/Articles/847951/

@mayli 好像可以创建一对 pipe ，先把 header 写进去，然后提交两个 splice(2) 任务（无须 link ？），一个连文件另一个连 socket 。这个不是 asyncio 层面的，但类似于计划中 kLoop 的 `loop.sendfile()` 实现，我还没试过，希望能帮上忙。

@haoliang 感谢夸奖！ trio 是好东西，异常扔得特别干净

@14 嗯惭愧……那个 PR 确实拖了好几年才做完……

@mayli 感谢分享！我赞同您提到的三点：1 、直接使用 io_uring 或者甚至是包装过的 liburing 来做业务逻辑，编程体验并不直观； 2 、深度利用队列需要一定技巧，比如可能需要在 SQ 提交之前修改顺序，才能将需要链接的元素排在一起，因为目前链接功能只能把挨在一起的几个元素连起来； 3 、io_uring 并不提供流量控制功能，需要调用者自己搞。

需要为其他读到这里的同学澄清的是，这些在 kLoop 中属于实现细节，参与开发的同学确实需要面对底层接口的复杂性，以及处理好各种接口异常，比如用发送队列做重试以提供高阶流量控制等等；然而，对于 kLoop 使用者而言，这些复杂性应该是封装在统一的 asyncio 接口之下的，比如用户只需调用 `loop.sendfile()`，而不需要考虑这个操作实际上可能链接了多个 io_uring 任务，包括创建管道、两次 splice 来连接文件和网络，以及流量控制所需要的重试（还没实现，大致猜测），以最高效的方式利用 io_uring 来完成任务。

@lixile draw.io ，好像现在叫 diagrams.net ，可以脱机当本地应用使

有幸在本书成书后的开发阶段抢先阅读过，非常认同“基础编程素养”和“编程理念”的部分，结合案例讲技巧，非常值得收藏。

@cmdOptionKana 很有道理！其实英文的 graph-relational 本身就没那么精准，那么叫图-关系模型应该也方便对照。

@adoal 是的是的，就怕这个。但是又不想翻译的太生硬……有什么好的建议吗😍😍？直接用英文 graph-relational 其实也挺好……

@so1n 谢谢肯定！新年快乐😺

@so1n 因为 V 站牛人太多，我竟看不出你到底是捧是踩，也不敢感谢也不敢解释，那我还是给你拜个晚年吧！元宵节快乐！

有个朋友做了个 AWS 里的 HA EdgeDB： https://github.com/aaronbrighton/cdk-edgedb-demo

@tabris17 嗯，你和 #35 @expexp 大体上是一个意思：现有体制很难动摇，开发者有学习成本和风险、运维有维护成本和单点风险，等等。这确实都是实际存在的困难，也是 EdgeDB 愿意去挑战的，新事物总是有早期使用者和大众接受期（如果幸运的话），好在早期使用者对 EdgeDB 给出的反馈是非常鼓舞人心的，因为 EdgeDB 确实解决了很多 SQL 体系中的问题，比如无须再使用 ORM 和 pgBouncer/pg-Pool 等，EdgeDB 的成本和风险对他们来说是可以接受的，这也是 EdgeDB 敢于走向大众的原因。另：EdgeDB 的 HA 是我做的，有 bug 我来修……

@tabris17 好问题！有多个原因，主要是方便支持多种编程语言，以及对 I/O 更好的掌控，同时还带来了支持更多功能的可能性，比如共享连接池和 CLI 相关的许多提升 DX 的工作流。理论上如果你只用 Python asyncio 写服务的话，可以内嵌一个 EdgeDB 模块，但节省不了太多资源，反而影响了 DX 和心情。

@devtiange
1 ）可以的，用 `--backend-dsn` 参数指定一个 PostgreSQL 的 DSN 就行，初次运行会创建内置库和 schema ，稍慢。https://www.edgedb.com/docs/guides/deployment/docker#edgedb-server-backend-dsn
2 ）可以有不同套路，传说中的 serverless 可以直接用 HTTP 向 EdgeDB 发送 EdgeQL 请求（ https://www.edgedb.com/docs/clients/90_edgeql/index#edgeql-over-http ），另外如果是 REST 的话，可以用 query_json() 直接让 EdgeDB 返回 JSON 字符串，后端无需处理直接回传给前端，节省额外的处理和序列化的工夫。接下来还在计划一种在 EdgeDB Server 中执行用户 WebAssembly 的功能，也可以用来做后端。

@feilaoda 有趣的语法～那生成 SQL 时是怎么知道要 join 哪个表的呢？是另有 schema 定义吗？

@sunng87 哟那可不敢当，只是 0.13 时写过点 zeromq 的东西而已

@kaellzt777 这确实是一个 bug ！已提交修复 PR： https://github.com/edgedb/edgedb-cli/pull/656

不过你可以先试试加上 --tlsv1.2：
curl --proto '=https' --tlsv1.2 -sSf https://sh.edgedb.com | sh

@sxfscool 感谢！

1 、https://github.com/edgedb/edgedb/issues/3440 （这个是你吗？）
2 、https://github.com/edgedb/edgedb/pull/3451

@bnm965321 对的，来 EdgeDB 一年了。好像确实没有直接提供 Relay 风格的 schema ， 不过看代码应该不难加。不过，你说的 GUI 是类似 https://github.com/edgedb/edgedb-studio 这样的吗？