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.

  • entwine@programming.dev
    2·
    3 days ago
    func get_album_by_id(album_id: int16): Album -> (
  get_albums()
  | find(func (this) -> this.id == album_id)
)

    I’ll admit I’m not a database guy, but isn’t this inefficient? It looks like it’s first querying the DB for all albums, then filtering the results in the interpreter. I assume the db engine has a more optimal implementation for when you do SELECT WHERE query, designed for whatever data structures it’s using internally.

    Also, minor nitpick but why does it have so many different ways to define a function body?

    func something() -> { ... }
func something() -> ( ... )
func something() -> ...
    • verstra@programming.devOP
      2·
      20 hours ago

      Two great questions!

      First one comes down to how database query optimization and predicate pushdown in particular. In this case, albums would probably have an index on albums.id column, which would optimize get_album_by_id into a single index lookup. Ideally, I would want to have an explicit function for this, something like sql::from_index("albums", "id", 3), but there is no such thing as explicit index lookup in PostgreSQL right now.

      Regarding different function syntaxes:

      • curly braces { ... } construct a new tuple (think object, struct, record),
      • parenthesis are used for precedence. They are not strictly needed for function bodies, but they do give a better visual guide to multi-line definitions, especially when using pipe operator.

      So:

      func something() -> { ... }  # constructs a new tuple
func something() -> ( ... )  # returns a value
func something() -> ...      # equivalent to ( ... )
  • atzanteol@sh.itjust.worksEnglish
    8·
    4 days ago

    Looks like an ORM? I used to use these a lot but these days I just write SQL. Far too many performance issues and fighting with a library to do what I could just write in SQL in 5 mins. Type safety doesn’t really seem like a big sell here. Most SQL libs already let you “getInt()”.

    • verstra@programming.devOP
      1·
      3 days ago

      Haven’t thought about but yes - it solves a few of the same problems as ORMs. Maybe the front page does not mention it, but with Lutra, you don’t get result.getInt(). You get generated Python classes / Rust structs that reflect the Lutra types.

    • 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·
          19 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.