4 ms·

Deuterium – Fully typed SQL query builder for Rust

66 points by aethertap 11y ago

ragna_rock_rock 11y ago
in Haxe with SPOD you can have a SQL DSL thanks to macro. for example User.manager.delete($id > 1000); User.manager.search($name in ["a","b","c"]); User.manager.search($id == 1 && { name : "Nicolas" }) User.manager.search($id < 10 && if( name == null ) true else $name == name) http://old.haxe.org/manual/spod http://old.haxe.org/manual/spod
neverminder 11y ago
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 http://slick.typesafe.com/doc/3.0.0/sql.html) would already be great.
- zsiciarz 11y ago
  There's https://github.com/sfackler/rust-postgres-macros https://github.com/sfackler/rust-postgres-macros for PostgreSQL.
- untothebreach 11y ago
  sflacker has a library that does this for Postgres: https://github.com/sfackler/rust-postgres https://github.com/sfackler/rust-postgres is the connection/query/etc part, and https://github.com/sfackler/rust-postgres-macros https://github.com/sfackler/rust-postgres-macros actually links with the postgres query parser to provide compile-time SQL syntax checking.
antimora 11y ago
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?
- aethertap 11y ago
  > 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.
- tragomaskhalos 11y ago
  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.
  - baq 11y ago
    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.
    - tragomaskhalos 11y ago
      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.
allan_s 11y ago
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.
ExpiredLink 11y ago
Fully typed - where? https://github.com/deuterium-orm/deuterium/blob/master/tests/insert.rs https://github.com/deuterium-orm/deuterium/blob/master/tests... Table and column names are ... strings!
looneysquash 11y ago
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?

66 points by aethertap 11y ago

in Haxe with SPOD you can have a SQL DSL thanks to macro. for example User.manager.delete($id > 1000); User.manager.search($name in ["a","b","c"]); User.manager.search($id == 1 && { name : "Nicolas" }) User.manager.search($id < 10 && if( name == null ) true else $name == name) http://old.haxe.org/manual/spod http://old.haxe.org/manual/spod

neverminder 11y ago

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 http://slick.typesafe.com/doc/3.0.0/sql.html) would already be great.

zsiciarz 11y ago
There's https://github.com/sfackler/rust-postgres-macros https://github.com/sfackler/rust-postgres-macros for PostgreSQL.
untothebreach 11y ago
sflacker has a library that does this for Postgres: https://github.com/sfackler/rust-postgres https://github.com/sfackler/rust-postgres is the connection/query/etc part, and https://github.com/sfackler/rust-postgres-macros https://github.com/sfackler/rust-postgres-macros actually links with the postgres query parser to provide compile-time SQL syntax checking.

antimora 11y ago

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?

aethertap 11y ago
> 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.
tragomaskhalos 11y ago
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.
- baq 11y ago
  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.
  - tragomaskhalos 11y ago
    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.

allan_s 11y ago

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.

ExpiredLink 11y ago

Fully typed - where? https://github.com/deuterium-orm/deuterium/blob/master/tests/insert.rs https://github.com/deuterium-orm/deuterium/blob/master/tests... Table and column names are ... strings!

looneysquash 11y ago

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?