Mikro-ORM 中自定义类型在 assign 操作后的 hydration 问题解析

问题背景

在使用 Mikro-ORM 进行数据库操作时，开发者可能会遇到一个特殊场景：当使用 wrap(entity).assign() 方法更新实体后，立即执行 find 操作时，某些使用自定义类型的属性会出现 hydration（水合）失败的情况。这个问题尤其在使用 PostgreSQL 的自定义几何类型（如 Point 类型）时表现得尤为明显。

问题现象

具体表现为：

1. 开发者定义了一个包含自定义类型的实体（如 Station 实体中的 position 属性使用 PointType）
2. 使用 assign 方法更新实体关系
3. 执行 persistAndFlush 后立即查询该实体
4. 发现自定义类型属性未被正确 hydrate，而普通属性则正常

技术分析

自定义类型实现

在示例中，PointType 继承自 Mikro-ORM 的 Type 基类，实现了以下关键方法：

• convertToDatabaseValue: 将 DTO 转换为数据库存储格式
• convertToJSValue: 将数据库值转换回 DTO
• 数据库函数转换方法等

问题根源

经过深入分析，发现问题出在 Mikro-ORM 的 identity map 和乐观锁定机制上：

1. 当执行第二次 findOneOrFail 时，实体已在 unitOfWork 中被找到
2. 由于启用了乐观锁定，会调用 lockAndPopulate 方法
3. 该方法内部调用 entityLoader.populate 时默认设置了 convertCustomTypes: false
4. 虽然 ORM 确实执行了关联查询，但自定义类型的转换被跳过

解决方案探索

开发者尝试了几种解决方法：

1. 直接设置 convertCustomTypes: true - 无效
2. 使用不同的 where 条件强制重新查询 - 有效（但非理想方案）
3. 禁用 identity map - 有效（但影响性能）

最佳实践建议

针对此类问题，推荐以下解决方案：

1. 明确主键属性：在实体中使用 PrimaryKeyProp 明确指定主键，避免类型推断问题
2. 自定义类型验证：确保自定义类型的转换方法正确处理边界情况
3. 查询策略调整：在需要完整 hydration 的场景下，可以考虑：
   • 使用 refresh: true 选项强制刷新
   • 在事务边界明确处执行完整查询
   • 合理设计数据加载策略

技术要点总结

1. Mikro-ORM 的 identity map 机制在提升性能的同时，也可能导致数据状态不一致
2. 自定义类型需要特别注意 hydration 过程
3. 乐观锁定与自定义类型的交互需要特别关注
4. 正确的类型定义可以避免不必要的类型断言

结论

这个问题揭示了 ORM 框架中高级功能（自定义类型、identity map、乐观锁定）交互时的复杂性。开发者在使用这些功能时需要深入理解其内部机制，并通过合理的编码实践和测试来确保数据一致性。Mikro-ORM 团队已确认此问题并在后续版本中进行了修复，建议开发者保持框架版本更新以获取最佳体验。