GRDB.swift 中 @Observable 与 Codable 的兼容性问题解析

在使用 GRDB.swift 进行 Swift 数据持久化开发时，开发者可能会遇到一个棘手的问题：当 Record 子类同时使用 @Observable 宏和 Codable 协议时，会出现 "_id" 列找不到的异常。本文将深入分析这一问题的根源，并提供解决方案。

问题现象

开发者在实现一个时间线应用时，定义了 TimelineItemBase 和 LocomotionSample 两个 Record 子类，并尝试通过关联查询获取数据。查询语句看似正确：

let request = TimelineItemBase
    .including(all: TimelineItemBase.samples)

但在执行时却抛出异常："column not found: _id"。错误信息中还显示出现了重复的字段：既有原始的 timelineItemId，又有一个自动生成的 grdb_timelineItemId。

问题根源

经过深入分析，发现问题出在 Swift 的 @Observable 宏与 Codable 协议的交互上：

1. @Observable 宏会自动为类生成一些内部属性，包括以 _ 开头的属性（如 _id）
2. 当类同时遵循 Codable 协议时，Swift 会尝试编码/解码这些内部属性
3. GRDB 的 Record 类已经实现了 Codable 协议
4. 这种多重交互导致了字段映射混乱

解决方案

针对这个问题，有以下几种解决方案：

方案一：移除 @Observable 宏

最简单的解决方案是暂时移除 @Observable 宏：

// 移除 @Observable 修饰符
public class TimelineItemBase: Record, Identifiable, Codable {
    // ...
}

方案二：自定义编解码实现

如果需要保留 @Observable，可以手动实现 Codable 协议方法：

@Observable
public class TimelineItemBase: Record, Identifiable {
    // ...
    
    private enum CodingKeys: String, CodingKey {
        case id, isVisit, startDate, endDate, source, deleted
        // 显式列出所有需要编解码的属性
    }
    
    required init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        // 手动解码每个属性
        try super.init(from: decoder)
    }
    
    override func encode(to encoder: Encoder) throws {
        var container = encoder.container(keyedBy: CodingKeys.self)
        // 手动编码每个属性
        try super.encode(to: encoder)
    }
}

方案三：分离数据层与 UI 层

更优雅的架构设计是将数据模型与 UI 模型分离：

1. 使用不可变的 Record 结构体作为数据层模型
2. 创建独立的 Observable 类作为 UI 层模型
3. 在两者之间进行转换

这种架构虽然需要更多样板代码，但能更好地隔离关注点，避免类似问题。

最佳实践建议

1. 对于简单的数据模型，优先考虑使用结构体而非类
2. 如果需要使用类，考虑是否真的需要 @Observable 宏
3. 当必须同时使用 @Observable 和 Codable 时，务必手动实现编解码逻辑
4. 对于性能敏感的场景，可以混合使用结构体和类，但要注意架构清晰

通过理解这些底层机制，开发者可以更自如地在 GRDB.swift 中使用 Swift 的各种现代特性，构建健壮高效的应用程序。