5 ms·

> Building a model of the SQL type system within the Rust type system is very impressive work. It also leads to really annoying problems, because the Diesel typ

> Building a model of the SQL type system within the Rust type system is very impressive work. It also leads to really annoying problems, because the Diesel types are so complex. Oh man have I felt this pain, trying to do anything mildly complex with Diesel's types is so ridiculously difficult. I once (foolishly) tried to write a generic repository implementation for database entities which could either have sqlite or postgres as a backend. I thought this would be very convenient for testing, being able to just keep all of the code the same safe for using a sqlite backed repository instead of a Postgres one. I gave up after about ~10 hours of battling incomprehensible error messages.

hot_gril 4y ago
I've given up on trying to wrap SQL in any way. Too many bad experiences. I just use it as-is with fully dynamic types. My go-to stack is Postgres + NodeJS, no Typescript. No query builders, no ORMs especially. Postgres is meant to be used on its own with a minimal client lib. It works beautifully. And my system is safer in the end because I take that time I would've spent fighting the type system / tooling and instead spend it writing integration tests. I get to do full TDD often. And the bugs I catch are never due to mishandled types.
- davidatbu 4y ago
  > And my system is safer in the end because I take that time I would've spent fighting the type system / tooling and instead spend it writing integration tests. I'm a type-safety kind of guy, but this argument (that time spent "fighting" the type system) is better spent writing tests when it comes to DB queries, has me very very curious. Would love others' opinions/experience on this!
  - hot_gril 4y ago
    Small clarification, the tests aren't on the DB queries alone. It's a full flow on a test backend, like it calls /editProfile to name a user "Bob" then calls /getProfile, and it expects the response to have `name: "Bob"`. It'll probably fail if I mess up a type and get "undefined," but it's also testing much more than that.
    - davidatbu 4y ago
      Ah, in that case, I'm much less interested :D , because that would mean that you let the untypedness of the DB queries propagate through pretty much the entire codebase.
      - hot_gril 4y ago
        Oh, yeah. Except I just remembered that I use an OpenApi spec, so at least the API param and return types are enforced.
metaltyphoon 4y ago
Lol, thats crazy. It’s 2 line changes in C# if you are using Entity Framework Core.
- DeathArrow 4y ago
  We are spoiled with C# and Entity Framework. :)
weiznich 4y ago
Diesel maintainer here. So first of all we are aware of the sometimes bad error message and we are working on solutions. There is already an unstable feature flag that improves some error messages and the next diesel release will include additional tools to improve the error messages in additional cases. In addition we try to change the language to give us more tools to control certain error messages emitted by the compiler, because mostly the error is large, but has a well known underlying issue that can be described much shorter. > I once (foolishly) tried to write a generic repository implementation for database entities which could either have sqlite or postgres as a backend. I thought this would be very convenient for testing, being able to just keep all of the code the same safe for using a sqlite backed repository instead of a Postgres one. It's generally not advice to test against different databases than you run in production. This is one of the reasons why these kind of things are not simple in diesel. Prefer running the tests against the "real" database system and use `Connection::begin_test_transaction()` to prevent polluting the database with test data. More generally speaking: Writing generic code involving diesel is likely an advanced topic, so don't expect it to work quickly. I usually advice people to not write this generic code, at least not if they just want to use diesel in their applications.

hot_gril 4y ago

I've given up on trying to wrap SQL in any way. Too many bad experiences. I just use it as-is with fully dynamic types. My go-to stack is Postgres + NodeJS, no Typescript. No query builders, no ORMs especially. Postgres is meant to be used on its own with a minimal client lib. It works beautifully. And my system is safer in the end because I take that time I would've spent fighting the type system / tooling and instead spend it writing integration tests. I get to do full TDD often. And the bugs I catch are never due to mishandled types.

davidatbu 4y ago
> And my system is safer in the end because I take that time I would've spent fighting the type system / tooling and instead spend it writing integration tests. I'm a type-safety kind of guy, but this argument (that time spent "fighting" the type system) is better spent writing tests when it comes to DB queries, has me very very curious. Would love others' opinions/experience on this!
- hot_gril 4y ago
  Small clarification, the tests aren't on the DB queries alone. It's a full flow on a test backend, like it calls /editProfile to name a user "Bob" then calls /getProfile, and it expects the response to have `name: "Bob"`. It'll probably fail if I mess up a type and get "undefined," but it's also testing much more than that.
  - davidatbu 4y ago
    Ah, in that case, I'm much less interested :D , because that would mean that you let the untypedness of the DB queries propagate through pretty much the entire codebase.
    - hot_gril 4y ago
      Oh, yeah. Except I just remembered that I use an OpenApi spec, so at least the API param and return types are enforced.

metaltyphoon 4y ago

Lol, thats crazy. It’s 2 line changes in C# if you are using Entity Framework Core.

DeathArrow 4y ago
We are spoiled with C# and Entity Framework. :)

weiznich 4y ago

Diesel maintainer here. So first of all we are aware of the sometimes bad error message and we are working on solutions. There is already an unstable feature flag that improves some error messages and the next diesel release will include additional tools to improve the error messages in additional cases. In addition we try to change the language to give us more tools to control certain error messages emitted by the compiler, because mostly the error is large, but has a well known underlying issue that can be described much shorter. > I once (foolishly) tried to write a generic repository implementation for database entities which could either have sqlite or postgres as a backend. I thought this would be very convenient for testing, being able to just keep all of the code the same safe for using a sqlite backed repository instead of a Postgres one. It's generally not advice to test against different databases than you run in production. This is one of the reasons why these kind of things are not simple in diesel. Prefer running the tests against the "real" database system and use `Connection::begin_test_transaction()` to prevent polluting the database with test data. More generally speaking: Writing generic code involving diesel is likely an advanced topic, so don't expect it to work quickly. I usually advice people to not write this generic code, at least not if they just want to use diesel in their applications.