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
      link
      fedilink
      arrow-up
      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
        link
        fedilink
        arrow-up
        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
          link
          fedilink
          arrow-up
          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.