It's odd to call it DSL for SQL. SQL is DSL as it can be.
I honestly fail to see (> cost) benefits of such tool. I realize it adds an additional layer abstraction which one could use to build additional functionalities on top, such as dialect translation, metadata emission. But why one would want to pay the cost of learning the new API and adhering limitation. For example, it is missing upsert feature. So what one supposed to do in this case?
> I realize it adds an additional layer abstraction which one could use to build additional functionalities on top
This is what got my attention about it - it provides a link that makes it more natural to play with SQL from Rust. You get some protection from typos and type errors, and you get the benefit of working with native types. I'd feel more confident working in this environment for those reasons than I would working with string-based SQL directly in my program. As for the incompleteness issues, it's still young and that seems like a solvable problem to me.
When I was a lad embedded SQL - like Oracle's Pro* C - was the thing, i.e. a C program with EXEC SQL blocks containing actual SQL, which was then run through a precompiler to convert into proper C with API calls.
Nowadays this technology seems almost completely forgotten, and I confess to being baffled as to why. Certainly existing implementations are execrable - just read up on indicator variables, or string handling, in Pro* C to see what I mean, but IMO the concept is sound if married to a modern 'host' language like C++ or Rust. One very strong advantage is that you are then actually writing your SQL in SQL, not using some baroque builder API.
As for typing, the precompiler could parse the SQL and see what result sets are being returned / what columns are being married to bind variables and so on, and then interrogate the database's metadata to determine their types. AFAIK no existing implementation does this.
this approach doesn't allow you to easily compose queries; you've got a SQL world and an application world which are mostly incompatible. here, you can easily stitch together the query you want while being free of worrying about SQL syntax correctness.
Horses for courses; if you have a lot of very vanilla SQL then sure, and this is clearly a very common use case because these sorts of APIs are very common now (aside: although often there's an argument for going straight to an ORM). On the other hand in a data-centric application that is exercising the database quite hard I want to be working in SQL directly, eg so I can try it out outside my code, and I don't fancy digging through a builder API document to see how (or if) I can hint an index, or use a CTE, etc.
um, what SQL being whatever you think it is has to do with what this project is?
this is a way of encoding SQL in Rust's syntax, which gives you compile-time verification of your queries, query composition, etc. in exchange for the fact that you're not writing queries as strings. of course it's missing features, that doesn't stop it from being useful. look at python's sqlalchemy for a great example of a DSL that's arguably better than SQL at being SQL.
I would really like to see something similar to Slick (Scala) for Rust. This one says it's an ORM, but a simple query compile time type checker (an example: http://slick.typesafe.com/doc/3.0.0/sql.html) would already be great.
I've never met one of these that I'm truly in love this.
This one looks like you don't use POD types, you use it's special types for the output of columns and rows.
I don't even know how to solve these problems. Perhaps I want something not possible.
You have some struct that represents your table. You want to insert into the table. You try to fill out your struct, but wait, you don't have an "id" yet. And that "created" timestamp field should really be the "DEFAULT" keyword in the insert statement too!
Then you have select queries that don't return all of columns, or that call functions and return extra columns. Do you define a struct for each query by hand?
i already created a ticket on github for this project, but I think it would be useful if rust libraries on github state if they build against 1.0.0 or against nightly , that would help chosing library.
I honestly fail to see (> cost) benefits of such tool. I realize it adds an additional layer abstraction which one could use to build additional functionalities on top, such as dialect translation, metadata emission. But why one would want to pay the cost of learning the new API and adhering limitation. For example, it is missing upsert feature. So what one supposed to do in this case?