Graphile/Crystal项目中导出模式丢失多态信息的问题分析

问题背景

在Graphile/Crystal项目中，当使用graphile-export导出模式时，PgCodec的多态(polymorphic)信息会丢失。这个问题影响了基于PostgreSQL的多态类型系统在导出后的正常工作。

问题表现

当开发者定义了一个多态接口和其实现类型后，通过graphile-export导出的模式中，PgCodec的polymorphic属性完全缺失。这导致在查询时出现"Don't know how to plan this as polymorphic"的错误。

技术分析

多态类型系统工作原理

Graphile/Crystal的多态类型系统允许在PostgreSQL中定义接口和实现类型。通过特殊的注释语法，开发者可以声明表作为接口，并指定哪些列对应哪些实现类型。

问题根源

问题的根本原因在于代码生成流程中的两个关键点：

1. 过早导出：PgCodecsPlugin在运行pgCodecs_recordType_spec钩子之前就定义了CodecSpec的EXPORTABLE，而多态信息是在这些钩子中添加的。

2. 引用缺失：PgCodec.refs属性在导出过程中也丢失了，这个属性是在pgRegistry_PgRegistry阶段(注册表最终确定时)由多态插件添加的。

解决方案

临时解决方案

开发者可以通过以下方式临时解决问题：

1. 仅导出注册表(registry)
2. 在运行时重新构建模式

根本解决方案

正确的解决方案需要调整代码生成流程：

1. 推迟EXPORTABLE的定义，直到Codec完全初始化
2. 确保所有后期添加的属性(如polymorphic和refs)都能正确导出

技术实现细节

在修复方案中，需要引入一种机制来重新定义已导出Codec的导出内容。这可能需要新增一个EXPORTABLE_OVERWRITE功能，它可以忽略已有的$exporter$factory，允许在Codec完全初始化后重新定义导出。

影响范围

这个问题主要影响：

1. 使用graphile-export导出多态模式的开发者
2. 依赖导出模式进行服务端渲染或静态分析的场景
3. 需要将模式定义与运行时分离的架构

最佳实践建议

在问题完全修复前，建议开发者：

1. 避免直接导出包含多态类型的完整模式
2. 考虑使用运行时模式构建替代方案
3. 密切关注Graphile/Crystal的版本更新，及时升级

总结

Graphile/Crystal中的多态类型系统是一个强大功能，但在导出流程中存在信息丢失的问题。理解其根本原因和解决方案有助于开发者更好地规划项目架构，避免潜在问题。随着项目的持续发展，这个问题将在未来版本中得到彻底解决。