基于Django-Graphene实现嵌套查询中关联Session数据的用户过滤

你的问题核心在于：当通过User -> trainings -> sessions嵌套查询时，默认的反向关联查询没有对Session的user字段进行过滤，导致返回了该Training下所有用户的Session。下面是具体的解决方案，完全适配你的代码场景：

步骤1：修改TrainingType，添加带参数的sessions字段及解析方法 #

默认的OptimizedDjangoObjectType生成的sessions字段没有参数，无法接收userId进行过滤。我们需要手动覆盖这个字段，并实现对应的解析逻辑：

class TrainingType(gql_optimizer.OptimizedDjangoObjectType):
    class Meta:
        model = Training
        fields = "__all__"
        convert_choices_to_enum = False

    # 手动定义sessions字段，添加必填的userId参数
    sessions = graphene.List(SessionType, userId=graphene.Int(required=True))

    def resolve_sessions(self, info, userId):
        # self代表当前的Training实例
        # 过滤出该Training下属于指定userId的Session，同时用gql_optimizer保持性能优化
        return gql_optimizer.query(
            self.sessions.filter(user_id=userId),
            info
        )

步骤2：更新GraphQL查询语句 #

现在你可以在嵌套查询中给sessions传入userId参数（直接复用顶层的$userId变量即可）：

query getUser($userId: Int!) {
  getUser(userId: $userId) {
    id
    username
    trainings{
      id
      name
      sessions(userId: $userId){
        id
        createdAt
        completedAt
        category
      }
    }
  }
}

为什么这个方案有效？ #

• 在resolve_sessions方法中，self是当前遍历到的Training对象，通过self.sessions可以直接获取该Training关联的所有Session查询集。
• 我们通过.filter(user_id=userId)精准过滤出属于目标用户的Session，避免返回无关数据。
• 保留gql_optimizer.query包装查询集，确保你的性能优化策略继续生效。

关于SessionType.get_queryset的补充说明 #

你提到是否可以在SessionType的get_queryset中处理，这个方法的作用是全局过滤Session的基础查询集，但它无法直接获取父级Training对象和传入的userId参数（除非通过上下文传递，但上下文更适合当前登录用户的场景，而非指定查询的用户）。因此，在TrainingType中实现resolve_sessions是更直接、灵活的方案。

内容的提问来源于stack exchange，提问作者Rafael Santos