Hacker News Reader

Comment by mythz | Hacker News Reader

From Drizzle's SQL-like example [1] by following classical SQL and including .select() first it wont to be able to provide type-safe queries. E.g. In litdb every from/join returns a new typed query builder where every reference is typed to a joined table that's included in the query.

Drizzle also uses its own custom query language e.g.

    .where(eq(countries.id, 10))

Whereas litdb lets you use the full expressiveness of SQL but ensures all references are typed:

    .where(c => $`${c.id} = 10`)

[1] https://orm.drizzle.team/docs/overview

View on HN

Does using template strings not compromise with type-safety? The drizzle example will be a compile time error for example if id wasn't a numeric column.

Seems a strange design choice for a library that claims to offer a type-safe sql builder.

Right the SQL expression is validating that you're referencing tables that are included in the query and that all column references exist, not that the parameter value matches the property type, although SQLite and MySQL does allow you to use a string to query an int column, e.g:

    SELECT * from Contact where id = '1'

With that said you can achieve something similar in litdb with a custom expression:

    const eq = <T,V>(ref:(x:T)=>V, value:V) => (x:T) => $`${ref(x)} = ${value}`

Which will type check that the value matches the column type:

    .where(eq(c => c.id, 2))

and fail type check when they don't:

    .where(eq(c => c.id, '2'))

Examples of other custom expressions: https://litdb.dev/#composable

Understood. IMHO it would be desirable to have built in support for all common crud operations to be end-to-end type-safe.

Reply on news.ycombinator.com