MikroORM 复合主键在关系过滤中的问题解析

问题背景

在使用MikroORM进行数据库操作时，开发者遇到了一个关于复合主键在关系过滤场景下的异常问题。具体表现为当通过loadItems方法加载关联实体并进行过滤时，ORM错误地使用了默认的id字段而非实际定义的复合主键字段。

问题复现

该问题出现在一个文档管理系统的数据模型中，主要涉及三个实体：

• Document（文档）
• DocumentVersion（文档版本）
• DocumentVersionReview（文档版本评审）

其中DocumentVersion实体使用了复合主键（由document和versionNumber组成），并通过一对多关系关联到DocumentVersionReview实体。当尝试加载某个文档的所有版本，并过滤出所有评审都已批准的版本时，ORM生成的SQL查询错误地引用了不存在的id字段。

技术分析

实体定义分析

DocumentVersion实体定义如下：

@Entity()
export abstract class DocumentVersion {
    [PrimaryKeyProp]?: ['document', 'versionNumber'];

    @ManyToOne(() => Document, { primary: true })
    document: Ref<Document>;

    @PrimaryKey()
    versionNumber: number;

    @OneToMany(() => DocumentVersionReview, review => review.documentVersion)
    reviews = new Collection<DocumentVersionReview>(this);
}

DocumentVersionReview实体定义：

@Entity()
export class DocumentVersionReview {
    @PrimaryKey()
    id: number;

    @ManyToOne()
    documentVersion: Ref<DocumentVersion>;

    @Property()
    approved: boolean;
}

错误SQL分析

问题出现在执行以下查询时：

const version = await doc.versions.loadItems({
    where: { reviews: { $every: { approved: true } } },
    orderBy: { versionNumber: 'DESC' }
});

ORM生成的错误SQL尝试使用t0.id字段进行过滤，而实际上应该使用复合主键字段document_id和version_number。

解决方案

临时解决方案

目前可以通过直接使用Repository查询来绕过此问题：

const version = await documentVersionRepo.findOne({
    document: doc,
    reviews: { $every: { approved: true } },
}, { orderBy: { versionNumber: 'DESC' } });

根本原因

此问题源于MikroORM在处理复合主键实体的关系过滤时，未能正确识别和使用复合主键字段。特别是在使用$every操作符时，ORM内部生成的子查询错误地假设了单列主键的存在。

最佳实践建议

1. 复合主键使用：在使用复合主键时，确保所有关联查询都明确指定所有主键字段
2. 关系过滤：对于复杂的关系过滤，考虑使用QueryBuilder构建更精确的查询
3. 版本兼容性：关注MikroORM的版本更新，该问题已在最新版本中得到修复

总结

复合主键在ORM中的处理往往比单列主键更复杂，需要开发者特别注意。MikroORM虽然在大多数场景下表现良好，但在某些边缘情况下（如本例中的关系过滤）仍可能出现问题。理解ORM的内部机制和生成SQL的原理，有助于开发者更快地定位和解决类似问题。