What’s preventing sea-query to become more statically typed?

[seivan]

Since Kysely can manage to create an insert statement that statically types the column types with the insert values, for example, a text column expects a string, why is Sea-Query currently blocked at offering that? Why don’t column names have types associated with them so that values used for the will give a compile error if they’re incompatible during an insert statement?

[tyt2y3]

Well, you can use SeaORM if you want to have compile-time schemas with typed structs. then you can do the following:

let res = Note::insert(note::ActiveModel {
    title: Set("title".to_owned()),
    num: Set(20),
    ..Default::default()
}).exec(db).await?;

[seivan]

Yeah I get that, but that’s full on ORM and I think this layer of static type checking should be on the query builder foremost. There’s a cognitive overhead with the ORM and its dozen derives and traits, but I’ve found that a statically typed checked query builder, even if the types are handwritten instead of generated does more and stays closer to SQL. If you haven’t, check out Kysely.

[tyt2y3]

You can cherry-pick a subset of features in SeaORM, or use it mostly as an entry point to the query builder.

[Expurple]

SeaQuery is dynamic and non-generic (fast to compile) by design. I think, you'd have to radically redesign it to the point that it's no longer the same library. For example, concrete Expr would become a generic Expr<RustType>. Same for all other AST types like FunctionCall. I think, this will never happen in upsteam SeaQuery.

If you want a type-checked query builder in Rust, consider using Diesel. It has emphasized type-checking from the beginning.

Although, I'm not familiar with Kysely (and not broadly familiar with ORMs and query builders in general). I'll check it out and post another comment later

[Huliiiiii]

Because Rust and TypeScript are designed for different goals. TypeScript is built on top of JavaScript, so its type system is designed to statically describe JavaScript’s dynamic behavior.
In contrast, Rust has a stricter and more static type system, designed for safety, performance, and systems-level programming.

In TypeScript, you can use type-level operations to extract the type of a specific field, such as using T["field"]. Rust's type system doesn't support this kind of type-level introspection, and achieving similar behavior would require procedural macros or reflection-like mechanisms, which are either limited or unsupported.

Sea query uses enums to represent columns, but Rust enums do not support variant-specific associated types or trait implementations, which limits certain type-level behaviors compared to what TypeScript allows.

This might be what you want. You can try to push this idea forward and see what problems you encounter in practice. For now, diesel is a more type-safe query builder.

trait TableTrait {}

trait ColumnTrait {
    type ColumnType: Into<Value>;
}

trait TableColumn<T: TableTrait>: ColumnTrait {}

struct Table {}

impl TableTrait for Table {}

struct Id;

impl ColumnTrait for Id {
    type ColumnType = i32;
}

impl TableColumn<Table> for Id {}

struct Text;

impl ColumnTrait for Text {
    type ColumnType = String;
}

impl TableColumn<Table> for Text {}

struct Inserter<T> {
    _phantom: std::marker::PhantomData<T>,
}

impl<T> Inserter<T> {
    fn new() -> Self {
        Self {
            _phantom: std::marker::PhantomData,
        }
    }
}

impl<T> Inserter<T>
where
    T: TableTrait,
{
    fn set_col<C>(mut self, col: C, value: impl Into<C::ColumnType>) -> Self
    where
        C: ColumnTrait + TableColumn<T>,
    {
        todo!()
    }
}

let inserter = Inserter::<Table>::new()
    .set_col(Id, 1)
    .set_col(Text, "hello");