Programming

hideshow 3 child comments

[–] verstra@programming.dev [S] 1 point 10 months ago (2 children)

I think that ORMs work great for 90% of cases, and abismally for the rest. They are also limited by the syntax and semantics of the language they are embedded in. For example, if you refer to a non-existing column, it would take a call to database to figure that out, and a cryptic error message with non-helpful code span.

hideshow 2 child comments

parent

[–] fxdave@lemmy.ml 1 point 10 months ago (1 child)

I use prisma ORM with kysely Query Builder. Prisma has its own schema language that we write with great IDE support and provides a parser to generate type-safe clients. It gives you the ts client generator by default. But for example, kysely also needs types and somebody wrote a prisma-kysely generator, which generates types for kysely based on the prisma schema. Prisma since then also have Typed SQL (type-safe raw sql). (Although, I haven't tried that yet.) So prisma can cover that missing 9% of cases, and there maybe 1% left for untyped raw sql.

Do you think Lutra can replace that 9+1% of cases? Or would it be also useful to write migrations in Lutra?

parent

hideshow 1 child comment

[–] verstra@programming.dev [S] 1 point 10 months ago

I do believe that it is possible to translate any SQL query to Lutra, that is Lutra can cover that last 1% of cases. There are a few caveats:

Some cases would produce very verbose Lutra code because they have special-case syntax in SQL, which makes them terse.
Lutra does not cover DDL (CREATE, ALTER, DROP, ADMINISTER). That's because Lutra is conceptually a "run-time" language for dealing with data and not schema modifications. Because of this, Lutra cannot be used for migrations.
Lutra is still in development, so you are likely to find cases that are not yet expressible. If you do, please report them, so they can be implemented. But I don't believe that there are cases that would conceptually clash with Lutra language design, like there are with most ORMs.