Diesel 2.0.0 contains the contributions of more than 130 people. More than 1700 commits were submitted over a span of 3 years.
As part of this release we introduced numerous new features and rewrote large parts of the internal structure. Check out our changelog for a complete list of changes. As this is a new major Diesel release it contains a number of breaking changes. Checkout our migration guide for details about how to handle those breaking changes.
This release contains the following parts:
Support the development of Diesel by sponsoring our work on GitHub
As a highlight Diesel 2.0.0 adds support for the following features:
GROUP BY supportUNION/INTERSECT queriesIn addition to the highlighted features Diesel 2.0.0 fixes several issues in our type level SQL representation such that it now correctly handles the following cases:
LEFT JOINS and INNER JOINSAND, OR and similar operatorsGROUP BY clausesDiesel 2.0 adds support for GROUP BY clauses for select queries.
This means queries like the following one will just work.
users::table.inner_join(posts::table)
.group_by(users::id)
.select((users::name, count(posts::id)))As this is the case for all other Diesel built-in query dsl, this construct is fully checked at compile time. This means Diesel will ensure that the GROUP BY clause is valid for the current query and it will also ensure that expressions appearing inside of your SELECT clause will match the aggregation rules provided by the current GROUP BY clause. Checkout the documentation of QueryDsl::group_by for examples.
Diesel 2.0 adds support for table aliasing. This enables users to write queries, where a table appears more than once in the corresponding FROM clause. For this Diesel provides a diesel::alias! macro that allows to define new alias for existing tables.
The following query demonstrates the support for this feature:
// Define new table alias for the existing `users` table
let users1 = diesel::alias!(schema::users as user1);
// Use the corresponding alias inside any existing query
users::table
.inner_join(users1.on(users::id).eq(users1.field(users::id))))
.select((users::id, users::name, users1.field(users::name)))
.order_by(users1.field(users::id))Again all of this is checked at compile time. So similar to a normal table, columns from aliases are only allowed to appear if the corresponding query actually uses the alias.
Selectable traitDiesel 2.0 features a new Selectable trait and derive that lets users declare that a type expects a certain kind of select clause. The major use case for this feature is to ensure that columns from a specific query are always requested in the right order for a corresponding type implementing Queryable. This also works for complex queries involving joins or other kinds of nesting.
#[derive(Queryable, Selectable)]
struct User {
id: i32,
name: String,
}
let first_user = users.select(User::as_select()).first(connection)?;Diesel enforces at type system level that once you provided such a select clause via User::as_select() you are only allowed to construct this type from the returned result of the corresponding query. This means there is no need to specify the User type twice in the query above.
UNION/INTERSECT/EXCEPT queriesDiesel 2.0 extents the query builder to support query combinations via UNION/INTERSECT/EXCEPT. This allows you to easily chain multiple queries together as long as they return fields of the same type. Queries like the following one are now supported:
users.select(user_name.nullable())
.union(animals.select(animal_name).filter(animal_name.is_not_null()))As always this is checked at compile time to reject invalid queries, like for example that ones containing select clauses with different fields. Checkout the documentation of CombineDsl for details.
The release of Diesel 2.0 does not only include the features listed above, but also marks the point where the following things can be provided by third party crates:
QueryDsl extensions to support previously unsupported SQL features. Checkout diesel_full_text_search for an exampleConnection infrastructureConnection implementations for existing backendsConnection and Backend implementations for previously unsupported backends. Checkout diesel-oci for an example.We encourage our community to try out those features. Especially we would like to see experimentation around:
Please get in touch with us for pointers, help and details.
With the release of Diesel 2.0 the planing for our next releases start. Hopefully they will not take as long as Diesel 2.0. We are looking for input on which features are wanted by our community. Please open a discussion thread with your idea in our discussion forum.
Weiznich will work on improving error messages for trait heavy crates based on a Rust Foundation Project Grant. This work will hopefully improve error messages for Diesel as well. If you are aware of bad error messages please submit a minimal example here.
Diesel 2.0 introduces substantial changes to Diesel’s inner workings. In some cases this impacts code written using Diesel 1.4.x. This document outlines notable changes and presents potential update strategies. We recommend to start the upgrade by removing the usage of all items that are marked as deprecated in Diesel 1.4.x.
Any code base migrating from Diesel 1.4.x to Diesel 2.0 is expected to be affected at least by the following changes:
Users of diesel_migration are additionally affected by the following change:
Users of BoxableExpression might be affected by the following change:
Users of tables containing a column of the type Array<T> are affected by the following change:
Users that implement support for their SQL types or type mappings are affected by the following changes:
ToSql implementationsFromSql implementationsno_arg_sql_function! macro is now pending deprecation. Users of the macro are advised to consider sql_function! macro.
Users of eq_any on the PostgreSQL backend might hit type rejection error in rare cases.
Users that update generic Diesel code will also be affected by the following changes:
Additionally this release contains many changes for users that implemented a custom backend/connection. We do not provide explicit migration steps but we encourage users to reach out with questions pertaining to these changes.
As part of this release we would like to welcome @Ten0 as part of the diesel core team.
Thank you to everyone who helped make this release happen through sponsoring, bug reports, and discussion on GitHub and Gitter. While we don’t have a way to collect stats on that form of contribution, it’s greatly appreciated.
In addition to the Diesel core team, 141 people contributed code to this release. A huge thank you to: