ElectricSQL中列可空性变更导致Schema缓存不一致问题解析

在ElectricSQL项目中，开发者遇到了一个关于数据库表结构变更与缓存同步的有趣问题。当用户将PostgreSQL表中的某个列从非空(not null)改为可空(nullable)后，虽然数据库层面已经成功执行了修改，但ElectricSQL客户端仍然报错提示该列不允许NULL值。

问题本质

这个问题的根源在于ElectricSQL的Schema缓存机制与PostgreSQL的复制协议之间的微妙差异。PostgreSQL的复制协议会在特定情况下发送Relation消息来通知表结构变更，但这个消息存在一定的局限性。

PostgreSQL复制协议细节

PostgreSQL的复制协议确实会在以下情况下发送Relation消息：

1. 首次通过复制连接流式传输表的行数据时
2. 表结构变更后首次流式传输行数据时

然而，Relation消息仅包含列名和数据类型等基本信息，并不包含列的约束信息，特别是关于列是否允许为NULL的约束信息。这种设计导致了ElectricSQL无法通过常规的复制消息获取到列约束的变更。

ElectricSQL的缓存机制

ElectricSQL使用了一个名为Electric.Postgres.Inspector.EtsInspector的模块来缓存表结构信息，这个模块被ShapeLogCollector使用。当表结构首次被查询时，ElectricSQL会缓存包括列可空性在内的完整约束信息。

问题在于，当列的可空性在数据库层面发生变更后：

1. PostgreSQL确实会发送新的Relation消息
2. 但Relation消息不包含可空性信息
3. ElectricSQL无法更新其缓存中的可空性约束
4. 导致缓存中的约束信息与实际数据库不一致

解决方案思路

针对这一问题，社区讨论了几种可能的解决方案：

1. 主动检测机制：当接收到包含NULL值的行数据时，可以检测该列在缓存中是否标记为非空，如果是则触发缓存刷新

2. 定期刷新机制：为缓存设置合理的过期时间，定期强制刷新表结构信息

3. 客户端通知机制：当应用检测到Schema变更时，可以主动通知ElectricSQL刷新缓存

对其他类型Schema变更的影响

值得注意的是，这个问题主要影响列的可空性变更。对于其他类型的Schema变更（如列类型变更、新增/删除列等），ElectricSQL能够通过Relation消息中的信息进行正确处理，因为这些信息包含在Relation消息中。当检测到这类变更时，ElectricSQL会主动使受影响的Shape缓存失效并清除Schema检查器中的缓存。

总结

这个问题揭示了数据库复制协议与ORM/数据访问层之间在Schema变更处理上的一个常见痛点。ElectricSQL团队需要设计一种机制来专门处理列约束变更的同步问题，特别是可空性约束的变更。对于开发者来说，在修改列的可空性约束后，可能需要采取额外步骤（如重启服务或手动刷新缓存）来确保ElectricSQL客户端能够获取到最新的Schema信息。