MikroORM中使用raw()函数在orderBy装饰器中引发的问题分析

问题背景

在使用MikroORM这个Node.js ORM框架时，开发者可能会遇到一个关于raw()函数在@OneToMany装饰器的orderBy选项中使用时产生的SQL错误。具体表现为当尝试通过原生SQL表达式进行排序时，系统会抛出"column [raw] does not exist"的错误。

问题现象

当开发者尝试在实体关联的orderBy选项中使用raw()函数时，例如：

@Entity()
export class EntityA {
    @OneToMany({
        entity: () => EntityB,
        mappedBy: (entityB: EntityB) => entityB.entityA,
        orderBy: {
            [raw("LENGTH(text)")]: "asc"
        }
    })
    orderedEntityBs: Collection<EntityB> = new Collection<EntityB>(this);
}

执行查询时会生成错误的SQL语句，试图查找名为[raw]的列而非使用原生表达式：

select `e0`.*, `o1`.`id` as `o1__id`... order by `o1`.`[raw]` asc

技术分析

这个问题源于MikroORM内部对装饰器中raw()函数的处理方式。在v6版本中，raw()函数在装饰器上下文中的行为与在查询方法(如find)中的行为不一致。

与v5版本的差异

值得注意的是，在MikroORM v5中，类似的expr()辅助函数没有这个问题。这是因为expr()只是一个类型辅助工具，不影响运行时行为。而v6中的raw()函数则需要在运行时进行特殊处理。

解决方案

临时解决方案

目前推荐的解决方案是使用@Formula装饰器创建一个计算属性：

@Entity()
export class EntityB {
    @Formula(a => `length(${a}.text)`)
    textLength!: number;
}

@Entity()
export class EntityA {
    @OneToMany({
        entity: () => EntityB,
        mappedBy: (entityB: EntityB) => entityB.entityA,
        orderBy: {
            textLength: "asc"
        }
    })
    orderedEntityBs: Collection<EntityB> = new Collection<EntityB>(this);
}

这种方法更符合ORM的设计理念，且能避免原生SQL带来的潜在问题。

未来可能的修复方向

开发团队正在考虑以下修复方案：

1. 为orderBy和where选项添加回调函数签名
2. 引入raw('...', { global: true })选项标记全局原始片段
3. 改进对装饰器上下文中原始片段的检测逻辑

最佳实践建议

1. 在装饰器上下文中，优先使用ORM提供的标准功能而非原生SQL
2. 对于复杂的排序需求，考虑使用计算属性(@Formula)
3. 关注MikroORM的版本更新，及时获取对此问题的官方修复
4. 在必须使用原生SQL时，确保在查询方法而非装饰器中使用raw()

这个问题展示了ORM框架在处理原生SQL与装饰器元数据时的复杂性，也提醒开发者在不同上下文中要注意API行为可能存在的差异。