Npgsql中Composite类型数组参数映射问题解析

问题背景

在使用Npgsql 8.0.3与PostgreSQL 16.2交互时，开发者在尝试通过NpgsqlDataSourceBuilder映射Composite类型数组参数时遇到了类型不支持的问题。具体表现为当调用存储过程并传入ApData[]数组参数时，系统抛出异常提示"'Models.ApData[]' is not supported for parameters having no NpgsqlDbType or DataTypeName"。

问题分析

新旧API差异

在Npgsql 7.0之前，开发者通常使用全局类型映射器NpgsqlConnection.GlobalTypeMapper.MapComposite来配置Composite类型的映射。这种方法虽然简单，但在新版本中已被标记为过时(obsolete)，推荐使用新的NpgsqlDataSourceBuilderAPI。

映射冲突

通过深入分析发现，问题的根源在于项目中同时存在两种不同的映射方式：

1. 在程序启动时使用旧的全局映射方式注册了Case_Data类型
2. 在业务代码中使用新的DataSourceBuilder方式注册ApData类型

这种混合使用新旧API的方式导致了映射冲突，使得DataSourceBuilder无法正确识别ApData类型的映射。

解决方案

统一迁移到新API

正确的做法是将所有Composite类型的映射统一迁移到新的DataSourceBuilder方式：

var dataSourceBuilder = new NpgsqlDataSourceBuilder(_connectionString);
dataSourceBuilder.EnableDynamicJson();

// 统一在此处注册所有Composite类型
dataSourceBuilder.MapComposite<ApData>("other_data.apdata");
dataSourceBuilder.MapComposite<Case_Data>("other_data.cpdata");

await using var dataSource = dataSourceBuilder.Build();

属性映射注意事项

对于Composite类型中的属性映射，需要注意以下几点：

1. 确保C#模型中的属性与PostgreSQL中的字段名称完全匹配
2. 可以使用PgName特性显式指定映射关系
3. 考虑使用NpgsqlNullNameTranslator来禁用名称转换

public class ApData
{
    [PgName("ID")]
    public int Id { get; set; }
    
    // 其他属性...
}

最佳实践

1. 避免混合使用新旧API：在迁移到新版本时，应一次性完成所有类型映射的迁移，避免新旧API混用。

2. 集中配置：建议在应用程序启动时集中配置所有需要的Composite类型映射，而不是分散在各个业务方法中。

3. 名称转换策略：根据项目需求选择适当的名称转换策略，确保C#属性名与数据库字段名正确对应。

4. 错误处理：在配置映射时添加适当的错误处理逻辑，便于快速定位映射问题。

总结

Npgsql从7.0版本开始引入了更灵活的DataSourceBuilder API来替代传统的全局类型映射器。在迁移过程中，开发者需要注意避免新旧API混用导致的映射冲突问题。通过统一使用新的DataSourceBuilder并正确配置属性映射，可以确保Composite类型数组参数能够正确传递到PostgreSQL存储过程中。