Mikro-ORM中STI模式下的鉴别器列查询优化

在Mikro-ORM中使用单表继承(STI)模式时，鉴别器列(discriminatorColumn)的处理方式有了重要改进。这个改进解决了在GraphQL等场景下查询嵌套数据时可能出现的问题。

问题背景

单表继承是ORM中常见的一种继承映射策略，它将继承体系中的所有类映射到同一个数据库表中，并通过一个特殊的鉴别器列来区分不同类型的记录。在Mikro-ORM中，开发者可以通过@Entity装饰器的discriminatorColumn选项来指定这个列。

然而，在之前的实现中，如果查询时没有显式请求这个鉴别器列(例如通过GraphQL查询时客户端没有请求该字段)，Mikro-ORM会完全从SQL查询中排除这个列。这导致在某些场景下，特别是使用GraphQL联合类型查询嵌套数据时，ORM无法正确识别记录的实际类型。

解决方案

最新版本的Mikro-ORM已经修改了这一行为，现在会始终在SQL查询中包含鉴别器列，即使客户端没有显式请求该字段。这与主键字段的处理方式类似，确保了类型识别的可靠性。

这种改进是自动的，开发者不需要进行任何额外配置。ORM会确保鉴别器列总是被加载，就像它总是加载主键一样。

最佳实践

在使用STI模式时，开发者应该注意以下几点：

1. 不需要在子类中重新定义鉴别器列属性，ORM会根据类类型自动处理值
2. 鉴别器列应该被声明为抽象基类的属性
3. 子类只需要通过discriminatorValue指定其鉴别值

例如正确的实体定义应该是：

@Entity({
  discriminatorColumn: "type",
  abstract: true,
})
export abstract class BasePerson {
  @PrimaryKey()
  id!: number;

  @Enum()
  type!: "customer" | "employee";

  @Property()
  name: string;
}

@Entity({ discriminatorValue: "customer" })
export class Customer extends BasePerson {
  @Property()
  amtMoney: number;
}

技术影响

这一改进特别有利于构建基于Mikro-ORM的GraphQL API。在GraphQL中，客户端可能不会显式请求鉴别器字段，但服务端仍然需要这个信息来正确解析联合类型和接口类型。现在Mikro-ORM确保了鉴别器信息总是可用，使得这类场景能够可靠工作。

总结

Mikro-ORM对STI模式下鉴别器列处理方式的改进，提升了框架在复杂查询场景下的可靠性，特别是在构建灵活API时。开发者现在可以更加自信地使用单表继承模式，而不必担心类型识别问题。这一变化遵循了"约定优于配置"的原则，通过合理的默认行为减少了开发者的认知负担。