GlueSQL ORM 实现与 AST Builder 类型公开探讨

GlueSQL ORM 的设计思路

在数据库应用开发中，ORM（对象关系映射）工具能够显著提升开发效率。最近在 GlueSQL 项目中，开发者正在探索如何为其实现一个简单的 ORM 层。这个 ORM 设计采用了 Rust 的派生宏（derive macro）方式，允许开发者通过简单的属性标注来自动生成数据库操作方法。

典型的 ORM 模型定义如下所示：

#[derive(GlueSqlModel)]
pub struct File {
    #[gluesql("PRIMARY KEY")] 
    pub id: u64,
    #[gluesql("NOT NULL")] 
    pub name: String,
    #[gluesql("NOT NULL")] 
    pub size: u64,
    #[gluesql("NOT NULL")] 
    pub created_at: NaiveDateTime,
    #[gluesql("NOT NULL")] 
    pub modified_at: NaiveDateTime,
}

这种设计会自动为结构体生成一系列数据库操作方法，包括：

• 从数据库行转换为 Rust 结构体的方法
• 将结构体转换为数据库行的方法
• 创建和删除对应数据库表的方法

AST Builder 的角色与类型公开问题

GlueSQL 的 AST Builder 是一个查询构建器，它通过链式调用生成抽象语法树（AST）。在 ORM 实现中，设计者希望使用 AST Builder 节点作为方法的返回类型，以便用户能够灵活地自定义这些查询。

然而，在实现过程中发现，并非所有的 AST Builder 节点类型都是公开的（public）。例如 TableNameNode 和 InsertSourceNode 等类型目前无法在外部使用，这限制了 ORM 功能的完整实现。

ORM 的扩展方向

GlueSQL 的 ORM 实现可以考虑两个主要方向：

1. 模式验证：确保数据库操作符合预定义的数据结构约束
2. 查询结果反序列化：将查询结果自动转换为 Rust 结构体

目前 AST Builder 主要承担查询构建的角色。一个潜在的设计思路是创建自定义的 Execute trait，这个 trait 可以：

• 接收 ORM 模式结构体
• 验证数据结构模式
• 将查询结果反序列化为 ORM 结构体

这种设计保持了灵活性，同时提供了 ORM 的便利性。开发者可以基于现有的 AST Builder 构建更高级的抽象，而无需修改核心库的实现。

技术实现建议

对于 AST Builder 类型的公开问题，建议将所有构建器节点类型设为公开，因为它们本来就是设计为公共接口的一部分。这将为 ORM 实现和其他扩展提供更大的灵活性。

在 ORM 的具体实现上，可以考虑分层设计：

1. 基础层：使用 AST Builder 构建查询
2. ORM 层：提供高级抽象和自动转换
3. 扩展层：允许开发者自定义行为

这种设计既保持了核心的简洁性，又为复杂应用场景提供了足够的扩展能力。