3 ms·

Seems very similar to [drizzle](https://orm.drizzle.team/ https://orm.drizzle.team/) - although drizzle is a more mature product.

• mythz 2y ago
  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 https://orm.drizzle.team/docs/overview
  • lf-non 2y ago
    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.
    • mythz 2y ago
      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 https://litdb.dev/#composable
      • lf-non 2y ago
        Understood. IMHO it would be desirable to have built in support for all common crud operations to be end-to-end type-safe.