22
Lutra: General-Purpose Query Language (lutra-lang.org)
submitted 10 months ago by to c/programming@programming.dev
8 comments fedilink hide all child comments
 

For the last year, I've been working on a query language that aims to replace SQL and data frame libraries. It's continuation of my work on PRQL and EdgeQL.

Now I need feedback on usability, ergonomics and overall design. Read trough the examples, check out the CLI & tell me what could be better.

you are viewing a single comment's thread
view the rest of the comments
[–] [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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 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?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] [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.
  • permalink
  • fedilink
  • source
  • parent