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?