Feedback on the usage of Diesel

[polc]

Hi,

I've been working with Diesel for almost one year now and overall, it's been a great experience. While using it I kept a small list of frustrations I encountered and thought about sharing them.

It's not a list of feature requests, I just feel like it would be nice to get feedback from some real-world apps. Also, after re-reading this list, I found that many of these bullets are about error messages.

• I had some panics when using Insertable, because Diesel doesn't detect when a non nullable field is missing in the struct.
• If a mismatch occurs between a Selectable type and the database schema, it’s not obvious to find the mismatching field (eg: a i64 instead of a i32).
• Composition between query parts as described in this guide has been difficult, because return types quickly become quite complexe. I’ve been using macros as a workaround and it has been working well.
• I’ve been missing CTE in many situations, especially because there is no workaround I know of, compared to window functions where I can just use sql.
• I feel like the ergonomic of left_join may be improved, particularly, the need to use assume_not_null in the left_join and nullable in the select.
• I’ve forgotten too many time that the select needs to be at the end the query, after joins and group_by, and got cryptic, difficult to find errors.
• impl Queryable <Nullable<...>> is not working and I’ve met this problem a few times. Forcing me to have a Option<SimpleArray<...> instead of just SimpleArray<...>, or an domain enum where Nullable was just one of the different variants.

[weiznich]

Thanks for writing this post. Such feedback is always valuable.

Also, after re-reading this list, I found that many of these bullets are about error messages.

I'm aware of that and I'm working on several levels to improve these messages, but that's nothing that moves fast (especially for the language level changes.). If you use a nightly compile you should get at least some improvements if you enable the nightly-error-messages feature flag.

I had some panics when using Insertable, because Diesel doesn't detect when a non nullable field is missing in the struct.

It's hard to reason about that due to the existence of default values at database level. It might be something to keep in mind for the next major release although. (We cannot change that before as it would likely break existing code).

If a mismatch occurs between a Selectable type and the database schema, it’s not obvious to find the mismatching field (eg: a i64 instead of a i32).

The next release will contain #3359 which should make it much easier to debug such issues.

Composition between query parts as described in this guide has been difficult, because return types quickly become quite complexe. I’ve been using macros as a workaround and it has been working well.

In the end the underlying problem here is quite similar to what iterators do. Having these complex types allow to reason about the query at compile time and gives maximum performance. In most cases you can shrink the types by boxing (via QueryDsl::into_boxed()), while keeping the essential information there. That has a slight performance cost for some backends, but otherwise that might help simplifying things.

I’ve been missing CTE in many situations, especially because there is no workaround I know of, compared to window functions where I can just use sql.

Both CTE's and window functions are something that we want to support some day. At least I personally did not have the time yet to implement that. If someone is interesting in one or the other I would be open to guide such an implementation.

I feel like the ergonomic of left_join may be improved, particularly, the need to use assume_not_null in the left_join and nullable in the select.

Can you provide an example where the usage of assume_not_null() is required? The usage of .nullable() in select is again an explicit design decision as we somehow need to signal that the result there is always nullable. I see no alternatives there.

I’ve forgotten too many time that the select needs to be at the end the query, after joins and group_by, and got cryptic, difficult to find errors.

This restriction is there to improve error messages. Without that it would be even harder to read an error that is generated by an mismatch between these clauses. This error would just point to load and call out that some overly generic trait is not implemented for your query type (which will be really large). While the current situation is not optimal, it keeps at least the error messages relatively small.

impl Queryable <Nullable<...>> is not working and I’ve met this problem a few times. Forcing me to have a Option<SimpleArray<...> instead of just SimpleArray<...>, or an domain enum where Nullable was just one of the different variants.

Can you provide an example for this case? That sounds strange for me.