@abersheeran 试了一下 没有想象中 hacky

继承一下 ForwardManyToOneDescriptor 把 get_object 改成直接报错，然后继承 ForeignKey 把 class attribute `forward_related_accessor_class` 改成刚刚创建的 class 就搞定了。`related_accessor_class` 同理。当然，这个需要把用到原生 ForeignKey 的地方都替换了，所以比较推荐 monkey patch `django.db.models.fields.related_descriptors` 里面的方法 这个文件前面有详细的说明.

用户输入的永远是 string

@abersheeran Django 也是标准 wsgi/asgi 任何不支持的东西裸写 wsgi/asgi 即可…… 甚至可以和别的框架混用 我经常这么干

@abersheeran 你都用了这么多私有方法了 离 monkey patch 还远吗 况且只需要开发个测试环境中

@23333333333 Python library 就得这么写才爽

@abersheeran 你只是把 n+1 变成了 没有兑现的承诺而已 restful 返回格式很固定 与其破坏承诺 不如在 dev 和自己 test 让 n+1 报错 生产环境就不会 n*1 了…… 类似 type checking 的思路

先记录一个 request 中一共需要哪些东西 才有可能知道怎么去优化查询

另外你这个治标不治本 只是把原来要查询的地方变成 None. Restful 的查询本来就是固定的 所以这种地方只在 dev 环境中和 CI 里面报错 上线环境就不会出错。
另外这个问题也是 restful 自己的问题 如果一个请求拿不到我要的数据 我自然会发一个新的请求……

要解决 N+1 问题 不能从单个 model 入手……
一定要从一个 request 的全局入手

只需要一个 resource: GraphqlResult.

程序员到底有什么特殊 以至于 50 岁之后会和别人不一样 要单独讨论

Stripe 就支持啊

Ansible 其实不错的

发消息: I request you to merge my branch into main branch.

名词解释就够了 你只是不知道名字而已

呃 不要开了这个先例…… 该谁做就谁做

在 nginx 那一层应该是复用的 你试试就知道了

实际上一个 tcp 经过那么多个 hop 实际情况很难控制

我估计那些文件本来就不是 utf8 的

这个需要浏览器处理吧……

@gzf6 当 A 成为了 突破口 就说明别的口突破不了啊 所以暗含了只能的意思