MikroORM中使用BigInt主键的正确姿势

问题背景

在使用MikroORM与better-sqlite驱动时，开发者遇到了一个关于主键类型的常见问题。当尝试使用bigserial类型作为自增主键时，在6.3.11版本后出现了NOT NULL约束错误，而之前版本却能正常工作。

问题分析

这个问题的本质在于开发者错误地将PostgreSQL特有的bigserial类型用在了SQLite数据库中。bigserial是PostgreSQL特有的自增大整数类型，不应该在其他数据库中使用。

在MikroORM 6.3.11版本中，框架对类型处理进行了优化，使得这种不正确的用法不再被允许，从而暴露出了原本就存在的问题。

解决方案

在MikroORM中，正确声明BigInt主键有以下几种方式：

1. 使用原生BigInt类型（推荐）：

@PrimaryKey()
id!: bigint;

2. 映射到字符串类型：

@PrimaryKey({ type: 'bigint' })
id!: string;

3. 显式声明自增：

@PrimaryKey({ autoincrement: true, type: 'bigint' })
id!: string;

技术细节

在底层实现上，MikroORM对不同数据库的主键处理有不同的策略：

• PostgreSQL支持serial和bigserial类型
• MySQL/MariaDB使用auto_increment属性
• SQLite使用AUTOINCREMENT关键字

6.3.11版本的变更主要是将类型检查逻辑下放到了各个数据库特定的SchemaHelper类中，使得类型检查更加严格和准确。这也是为什么之前版本能"工作"（实际上是忽略了类型不匹配），而新版本会报错的原因。

最佳实践

1. 始终使用与目标数据库兼容的类型声明
2. 对于跨数据库应用，使用最通用的类型声明方式
3. 避免使用数据库特有的类型（如PostgreSQL的serial）
4. 在声明主键时，优先使用原生BigInt类型以获得最佳类型安全

总结

这个问题很好地展示了类型系统在ORM中的重要性。MikroORM通过逐步完善类型检查，帮助开发者写出更加健壮和可移植的代码。开发者应该遵循ORM的最佳实践，而不是依赖特定版本的"宽容"行为。

对于需要处理大整数主键的场景，使用标准的bigint类型声明是最安全可靠的选择，这能确保代码在不同数据库和不同MikroORM版本间的兼容性。