Querydsl与MongoDB关联文档查询的优化实践

本文探讨了在使用querydsl查询包含`@documentreference`关联字段的mongodb集合时遇到的问题，即无法通过关联文档的字段进行有效搜索。核心解决方案是替换`@documentreference`为`@dbref`，这使得querydsl能够正确处理嵌套字段查询，从而实现对关联集合内部字段的灵活搜索。文章详细介绍了实现步骤、代码示例及两种关联注解的适用场景。

Querydsl与MongoDB关联文档查询的挑战

在Spring Data MongoDB中结合Querydsl进行数据查询时，处理包含关联文档（而非嵌入式文档）的集合是一个常见需求。特别是当一个主文档通过引用（reference）方式关联另一个文档时，我们可能需要根据被引用文档的字段来过滤主文档。然而，在使用@DocumentReference注解进行关联时，QuerydslPredicateExecutor在处理被引用文档的字段查询时可能会遇到障碍，导致查询结果为空。

考虑以下两个MongoDB集合模型：Subject（主题）和SubjectType（主题类型）。Subject文档通过subjectType字段关联到SubjectType文档。

// Subject.java
@Data
@Builder
@Document(collection = "subject")
@JsonInclude(JsonInclude.Include.NON_NULL)
public class Subject {
    @Id
    private String id;
    @Field("full_name")
    private String fullName;
    @Field("subject_yupe")
    // 初始使用 @DocumentReference
    @DocumentReference(lazy = true) 
    private SubjectType subjectType;
    // other fields
}

// SubjectType.java
@Data
@Builder
@Document(collection = "subjecttype")
@JsonInclude(JsonInclude.Include.NON_NULL)
public class SubjectType {
    @Id
    private String id;
    @Indexed(unique = true)
    @Field("name")
    private String name;
}

为了集成Querydsl，我们通常会定义一个继承了MongoRepository、QuerydslPredicateExecutor和QuerydslBinderCustomizer的仓库接口：

// SubjectRepository.java
@Repository
public interface SubjectRepository extends MongoRepository, 
                                           QuerydslPredicateExecutor, 
                                           QuerydslBinderCustomizer {
    @Override
    default void customize(QuerydslBindings bindings, QSubject subject) {
        // 自定义字符串绑定，实现不区分大小写的包含查询
        bindings.bind(String.class).first((StringPath path, String value) -> path.containsIgnoreCase(value));
    }
}

并通过Spring MVC控制器暴露查询接口：

// SubjectController.java
@RestController
@RequestMapping("/api/subjects")
public class SubjectController {
    @Autowired
    private SubjectService subjectService; // 假设有一个服务层处理业务逻辑

    @GetMapping("/search")
    public ResponseEntity> search(@QuerydslPredicate(root = Subject.class) Predicate predicate) {
        // 调用服务层进行查询并返回结果
        return ResponseEntity.ok(subjectService.findAll(predicate));
    }
}

当通过Subject自身的字段（如fullName）进行查询时，一切正常，MongoDB会生成类似如下的查询语句并返回正确结果：

find using query: { "full_name" : { "$regularExpression" : { "pattern" : ".*\\Qgius\\E.*", "options" : "i"}}}

然而，当尝试通过关联的SubjectType文档的字段（如subjectType.name）进行查询时，尽管MongoDB生成的查询语句看起来是正确的（例如：{ "subject_type.name" : { "$regularExpression" : { "pattern" : ".*\\QEntit\\E.*", "options" : "i"}}}），但查询结果却是一个空数组。即使是尝试查询subjectType.id，也可能遇到类似问题或生成不符合预期的查询。

问题分析：@DocumentReference的局限性

@DocumentReference是Spring Data MongoDB在较新版本中引入的注解，旨在提供一种更轻量级的文档引用机制，它默认只存储被引用文档的_id字段，并在需要时进行惰性加载。其设计初衷是为了避免自动加载关联文档，从而提高性能和减少内存消耗。然而，在结合Querydsl进行复杂查询时，尤其是在需要根据被引用文档的字段进行过滤时，@DocumentReference可能不会自动触发MongoDB的引用解析或“查找（lookup）”操作，导致QuerydslPredicateExecutor无法有效利用其进行跨文档查询。尽管MongoDB的查询语法支持点式路径（如subject_type.name）来查询嵌套字段，但对于@DocumentReference这种逻辑上的引用，Spring Data MongoDB的Querydsl集成可能无法将其转化为MongoDB能够直接执行的有效查询，或者在执行后无法正确匹配。

REimagine Home: AI

上传室内图片，AI自动为你生成多种家居软装效果图

下载

解决方案：切换至@DBRef

解决上述问题的直接有效方法是将Subject类中的@DocumentReference注解替换为@DBRef。@DBRef是Spring Data MongoDB中更为传统的文档引用注解，它在MongoDB层面创建了一个DBRef对象，包含被引用文档的_id和集合名称。Spring Data MongoDB对@DBRef提供了更完善的支持，包括在Querydsl查询时的自动解析和处理。

修改Subject类如下：

// Subject.java (更新后)
@Data
@Builder
@Document(collection = "subject")
@JsonInclude(JsonInclude.Include.NON_NULL)
public class Subject {
    @Id
    private String id;
    @Field("full_name")
    private String fullName;
    @Field("subject_yupe")
    // 将 @DocumentReference 替换为 @DBRef
    @DBRef(lazy = true) 
    private SubjectType subjectType;
    // other fields
}

在将@DocumentReference更改为@DBRef之后，无需修改SubjectRepository或控制器代码。QuerydslPredicateExecutor将能够正确地解析subjectType.name或subjectType.id等路径，并生成有效的MongoDB查询，从而返回预期的结果。例如，当查询subjectType.name时，MongoDB的日志会显示类似的查询，但这次会返回匹配的文档：

find using query: { "subject_type.name" : { "$regularExpression" : { "pattern" : ".*\\QEntit\\E.*", "options" : "i"}}}

@DBRef与@DocumentReference的对比与选择

选择建议：

• 如果您需要利用Querydsl或Spring Data MongoDB的默认查询机制，通过关联文档的字段进行过滤、排序等操作，那么@DBRef是更稳健的选择。它提供了更强的集成度和更少的配置复杂性。
• 如果您希望对文档引用有更细粒度的控制，例如只存储ID，并且在业务逻辑层手动根据ID去查找关联文档，或者您的查询逻辑不涉及被引用文档的字段，那么@DocumentReference可能更适合。

总结

在Spring Data MongoDB结合Querydsl进行关联文档查询时，当遇到@DocumentReference无法有效查询关联字段的问题时，切换到@DBRef通常是最佳解决方案。@DBRef提供了更成熟的Querydsl集成支持，能够确保通过关联文档的嵌套字段进行查询时，MongoDB能够生成并执行正确的查询，并返回预期结果。理解这两种引用注解的区别及其在查询上下文中的行为，对于构建高效且可维护的MongoDB应用程序至关重要。