A safe, extensible ORM and Query Builder for Rust
In contrast to the last release most changes in this release are minor or internal. We've added support for newer versions of some dependency crates (libsqlite-sys, uuid, ipnetwork).
Diesel CLI got a command line flag to check if a generated schema matches the already existing one. This is useful for CI setups to check there if the committed generated schema file matches the committed migrations.
We've added support for the diesel_mange_updated_at('table_name') SQL function on SQLite. This function handles the setup of an trigger that automatically updates the updated_at column on update operations.
Additionally several helpers were added to support the deserialisation of tuples and composite types on PostgreSQL.
As always, a full list of changes can be found it in the changelog
Thank you to everyone who helped make this release happen through bug reports, and discussion on 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, 29 people contributed code to this release. A huge thank you to:
This is a small bugfix release, addressing an issue with MySQL 8.0. The behavior of the C API in libmysqlclient changed in this version of MySQL, causing problems when a connection pool was used with Diesel.
If you are not using MySQL, or are on a version older than 8.0, this release does not affect you.
This release contains two major bugfixes. This release fixes the behavior of unsigned types on MySQL, and a compile time issue caused by the use of #[sql_name] in sql_function! with no return type. This release only affects users who are using unsigned types on MySQL, or who had code which failed to compile with 1.3.1.
This release includes a couple of major changes to how Diesel projects are developed. In the past, we've had 2 ways to generate schema.rs. A procedural macro called infer_schema!, and a CLI command diesel print-schema. We've recommended using the CLI command for a long time, but infer_schema! was still useful for early prototypes.
At the beginning of a project, your database schema changes much more frequently. It's extremely annoying to have to remember to run a second command after running your migrations.
Diesel CLI 1.3 now supports a configuration file to customize its behavior. One of the new capabilities this provides is the ability to automatically regenerate schema.rs whenever you run or revert a migration. This means you no longer have to remember to run diesel print-schema when things change.
Because of this, we are deprecating diesel_infer_schema. 1.3 will be the final release of that crate. However, diesel_infer_schema 1.3 will continue to work with diesel until at least Diesel 2.0. You can see all of the capabilities of the new configuration file at http://diesel.rs/guides/configuring-diesel-cli.
This release also includes a complete redesign of the sql_function! macro. The new syntax is significantly closer to normal Rust. For example, what used to be written as:
sql_function! {
lower, lower_t, (x: Text) -> Text,
"Here are the docs for `lower`
It's awkward to make multiline"
}
Can now be written as:
sql_function! {
/// Here are the docs for `lower`
/// It's just a normal doc comment.
fn lower(x: Text) -> Text;
}
The new form also supports much more than the old one, including aggregate functions, function renaming, and generic functions. Things like MAX could previously not be expressed with sql_function!. However, now the definition looks like this:
sql_function! {
#[aggregate]
fn max<ST: SqlOrd + IntoNullable>(expr: ST) -> ST::Nullable;
}
Finally, the redesigned sql_function! supports user defined functions on SQLite. SQLite differs from other databases, in that custom functions aren't defined in SQL. Instead you give it a C function pointer to use for the body. With Diesel, you can just give us any Rust closure that takes appropriate argument types, and we'll handle gluing that to SQLite for you.
You can find examples for all of this in the docs for sql_function!.
In addition to the headline features, this release includes a ton of quality of life changes including expanded support for locking clauses, more global support for mathematic operators, and more. As always, for a full list of changes you can find it in [the changelog].
[the changelog]: https://github.com/diesel-rs/diesel/blob/v1.3.0/CHANGELOG.md
Thank you to everyone who helped make this release happen through bug reports, and discussion on 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, 12 people contributed code to this release. A huge thank you to:
This release contains several long awaited features.
We've re-introduced the ability to use bind params with the sql function, in a way which is harder to mis-use. This functionality was present prior to 1.0, but was removed when sql_function was added over concerns about its use with the rest of the query builder. Recent developments have proved those concerns to be valid, but this new API fills that niche. Thanks to @notryanb for taking the lead on this feature.
We've also added the ability to insert from a select statement (e.g. queries in the form of INSERT INTO table (...) SELECT .... This is a feature request that has come up repeatedly since release, and we're happy to finally bring it to you. We've also added alternate forms of our insert API which feel better when used with select statements. You can find the full details in the CHANGELOG.
Finally, we've rewritten our custom dervies from scratch to take advantage of new diagnostic tools in recent versions of nightly Rust. If you turn on the unstable feature of Diesel on a nightly compiler, you'll find that you get dramatically improved error messages from our derives. For the best error messages, you should also set RUSTFLAGS="--cfg procmacro2_semver_exempt".
Additionally, as of this release, Diesel is now powered by the blockchain. Because it's 2018 and that's how it works now I guess. See the CHANGELOG for full details.
In addition to the headline features, there were a ton of features that we don't have time to mention here. As always, for a full list of changes you can find a full list in the CHANGELOG.
Thank you to everyone who helped make this release happen through bug reports, and discussion on Gitter. While we don't have a way to collect stats on that form of contribution...
In addition to the Diesel core team, 14 people contributed code to this release. A huge thank you to:
This release fixes a minor issue with our r2d2 support. In 1.1 we recommend that people access r2d2 via diesel::r2d2. However, r2d2 has a type called Error, which was shadowed by our own type called Error in that same module, making it inaccessible. This release adds an alias PoolError to point at r2d2::Error.
Thanks to YetAnotherMinion for working on this release.
The primary focus of this release was improving the ergonomics of adding support for new types in Diesel.
For implementing new SQL types, we've added #[derive(SqlType)] which implements many traits that you need to implement for every SQL type. See the documentation for HasSqlType for details on this derive.
For implementing new mappings, we've added #[derive(FromSqlRow)] and #[derive(AsExpression)]. These derives will replace the majority of the boilerplate that was previously required when supporting new types. Adding support for new types in Diesel 1.1 should only require implementing FromSql and ToSql. The derives will handle the rest.
We've also provided FromSql impls for *const str and *const [u8]. Due to the design of FromSql, we can't provide impls for &str and &[u8] without a breaking change. However many impls just need to parse a string or some bytes, and don't need the allocation that would come from String or Vec<u8>. This will require unsafe code to use, but should make certain implementations more efficient.
Finally, we've restructured how our serialize/deserialize modules are structured, and provided type aliases to make implementations of FromSql and ToSql more consise.
r2d2_diesel is Now Part of DieselFinally, this release merges r2d2_diesel into Diesel itself. The main benefit of doing this is that we can implement Connection for PooledConnection, removing the need for explicit &* when using r2d2. This should also help to prevent version mismatches when changing Diesel versions.
To use the new r2d2 support, remove r2d2 and r2d2_diesel from your Cargo.toml. Add the r2d2 to your enabled features on diesel. Replace extern crate r2d2 with pub use diesel::r2d2. Replace any r2d2_diesel:: with diesel::r2d2::.
In addition to the headline features, there were dozens of smaller additions which should make using Diesel even better! As always, you can check the CHANGELOG for a full list of changes in this release.
In addition to the Diesel core team, 8 people contributed to this release. A huge thank you to:
We didn't quite make it for 2017, but Diesel 1.0 is finally here! There are no changes between Diesel 1.0 and 1.0.0-rc1.
1.0.0 marks stability for Diesel. While there are many more features that will be added in the future, there will be no breaking changes from this point forward without a major version bump (which we do not anticipate happening for many years).
A lot has happened since Diesel 0.1 was released over 2 years ago. While it would be impossible to list every major change that has happened since then, here are a few highlights:
diesel print-schema replaced infer_schema! as the go-to way to
infer your database schema.It's been a great honor to watch this community grow and thrive as this library has developed. I look forward to continuing to evolve Diesel, and seeing how far it can go.
In addition to the Diesel core team, 98 people have contributed to Diesel. A huge thank you to everyone who made this and every prior release possible:
Happy holidays!
This release contains no major code changes. There are a handful of minor bug fixes (the most notable being that SQLite no longer panics when we receive SQLITE_BUSY), but most changes are related to ensuring that our API documentation renders better.
We do not expect any further changes to the codebase of any kind (other than the version number) between this release and 1.0.0. Assuming no critical issues are found with this release candidate, the code as it exists at this point will be released as 1.0.0 on 2017-12-30.