Npgsql.EntityFrameworkCore.PostgreSQL 中 SplitQuery 与枚举/hstore 类型的初始化问题解析

问题背景

在使用 Npgsql.EntityFrameworkCore.PostgreSQL 进行开发时，我们可能会遇到一个特殊场景：当数据库通过脚本初始化而非 EnsureCreated 方法创建时，如果数据模型中包含枚举类型或 hstore 类型，并且启用了 SplitQuery 查询拆分行为，首次查询会抛出 InvalidCastException 异常。

技术细节分析

1. 问题本质

这个问题的核心在于 PostgreSQL 类型系统的初始化时机。Npgsql 驱动程序在首次连接时会从数据库中加载所有类型定义，包括枚举和 hstore 等扩展类型。当我们通过脚本手动创建数据库时，这些类型是在 Npgsql 已经建立连接后才创建的，导致驱动程序无法识别这些新类型。

2. SplitQuery 的影响

SplitQuery（查询拆分）是 EF Core 提供的一种查询优化策略，它会将复杂查询拆分为多个独立查询。在这种模式下，EF Core 需要预先了解返回结果的类型信息。当类型系统未正确加载时，就会导致类型识别失败。

3. 与 EnsureCreated 的区别

使用 EnsureCreated 方法时不会出现此问题，因为 EF Core 会在创建数据库结构后自动重新建立连接，确保类型系统同步。而手动执行脚本后，原有的连接仍然保持着，类型信息没有更新。

解决方案

解决此问题的关键在于强制 Npgsql 重新加载类型信息。可以通过以下方式实现：

await connection.ReloadTypesAsync();

这个方法会强制 Npgsql 从数据库重新加载所有类型定义，确保驱动程序能够识别新创建的枚举和 hstore 类型。

最佳实践建议

1. 初始化顺序：在数据库创建脚本执行完毕后，立即调用 ReloadTypesAsync 方法
2. 连接管理：考虑在执行脚本后关闭并重新打开连接，这也会触发类型重新加载
3. 开发环境优化：对于大型模型，可以继续使用脚本初始化方式，只需确保正确处理类型加载

技术原理延伸

PostgreSQL 的类型系统是动态的，允许运行时创建新类型（如枚举）。Npgsql 作为客户端驱动程序，需要在连接时获取这些类型信息才能正确处理查询结果。这种设计虽然灵活，但也带来了初始化顺序上的复杂性，特别是在使用高级 ORM 功能如 SplitQuery 时。

理解这一机制有助于开发者更好地处理 PostgreSQL 特有的类型系统问题，特别是在复杂的应用初始化场景中。