Deuterium – Fully typed SQL query builder for Rust

https://github.com/deuterium-orm/deuterium

by aethertap • 11 years ago

66 13 11 years 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) would already be great.

zsiciarz• 11 years ago

There's https://github.com/sfackler/rust-postgres-macros for PostgreSQL.

untothebreach• 11 years ago

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

antimora• 11 years 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• 11 years 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.

tragomaskhalos2• 11 years 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.

baq2• 11 years 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.

baq2• 11 years ago

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.

allan_s• 11 years 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.

ragna_rock_rock• 11 years 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

ExpiredLink• 11 years ago

Fully typed - where?

https://github.com/deuterium-orm/deuterium/blob/master/tests...

Table and column names are ... strings!

looneysquash• 11 years 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?

Deuterium – Fully typed SQL query builder for Rust

Related Stories