Serde and database drivers

1

Just want to propose using serde to simplify the usage of database drivers. Querying data can then be as simple as

let query = "..."; // some SQL Query
let resultset: ResultSet = try!(connection.query_statement(query));
#[derive(Deserialize)]
struct MyRow {
    ...
}

let result: Vec<MyRow> = try!(resultset.into_typed());

I tried it with a yet experimental, but reasonably working driver for SAP's HANA (see hdbconnect::code_examples - Rust for more details) and ... would be interested in other opinions!

2

I don't know much about Diesel but did you consider implementing a Diesel Backend and then using its Queryable trait rather than Deserialize? Diesel has already implemented a mapping from database rows to structs, we shouldn't reimplement that in an incompatible way unless there are advantages.

3

You hit a point, I have to admit that I had looked at DIesel a long time ago only...

What was the reason for Diesel to come up with its own de/serialization annotation? Was it just a matter of timing (serde not being there or not yet mature enough when they started with Queryable)? I don't see a good reason not to use serde's de/serialize in this place.

Independent of this, the proposal shown in hdbconnect offers a bit more: you can e.g. deserialize directly into a , if you know that you only get a single row with a single field that can be deserialized into a (where is an elementary rust type, not a struct).

Generally, I am sceptic regarding the ORM aspect of Diesel and other frameworks. SQL is a very powerful language that allows to retrieve datasets with aggregations and joins and groupings and conversions etc in a structure that is totally different from the structure of the physical tables. ORM's have the tendency to keep you from using the full SQL capabilities by emphasizing the physical data structure.

Also, managing the lifecycle of database artifacts can be really complicated and requires a framework of its own, especially for updates (schema migrations).

Of course, with the decision not to deal with table and view definitions there remains a gap: the rust compiler cannot be used to check that the coded SQL query is syntactically correct. But isn't this acceptable, since you of course test your app before you ship it?