Lutra
lutra-lang.org

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.

  • verstra@programming.devOP
    1·
    3 days ago

    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.

    • fxdave@lemmy.ml
      1·
      3 days ago

      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?

      • verstra@programming.devOP
        1·
        21 hours 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.