diesel/CHANGELOG.md

975 lines
35 KiB
Markdown
Raw Normal View History

# Change Log
All user visible changes to this project will be documented in this file.
This project adheres to [Semantic Versioning](http://semver.org/), as described
for Rust libraries in [RFC #1105](https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md)
## Unreleased
2017-07-25 01:00:17 +03:00
### Added
* Added helper types for inner join and left outer join
* `diesel::debug_sql` has been added as a replacement for `debug_sql!`. This
function differs from the macro by allowing you to specify the backend, and
will generate the actual query which will be run.
* `diesel::pg::PgConnection`, `diesel::mysql::MysqlConnection`, and
`diesel::sqlite::SqliteConnection` are now exported from `diesel::prelude`.
You should no longer need to import these types explicitly.
2017-07-12 07:09:37 +03:00
* Added support for the Decimal datatype on MySQL, using the [BigDecimal crate][bigdecimal-0.16.0].
* Added support for the [Range][range-0.16.0] type on postgreSQL.
2017-08-05 22:48:39 +03:00
* `infer_schema!` will now automatically detect which tables can be joined based
on the presence of foreign key constraints.
### Changed
* The deprecated `debug_sql!` and `print_sql!` functions will now generate
backend specific SQL. (The specific backend they will generate for will be
arbitrarily chosen based on the backends enabled).
2017-08-04 20:00:21 +03:00
* `#[belongs_to]` will no longer generate the code required to join between two
2017-08-05 22:48:39 +03:00
tables. You will need to explicitly invoke `joinable!` instead, unless you are
using `infer_schema!`
2017-08-04 20:00:21 +03:00
### Removed
* `debug_sql!` has been deprecated in favor of `diesel::debug_sql`.
* `print_sql!` has been deprecated without replacement.
* `diesel::backend::Debug` has been removed.
2017-08-04 20:00:21 +03:00
### Fixed
* Diesel now properly supports joins in the form:
`grandchild.join(child.join(parent))`. Previously only
`parent.join(child.join(grandchild))` would compile.
Refactor encoding `BigDecimal` on PG I had originally worked on this as part of 0.15.2, but have been sitting on it until a new version was released so we could use `to_bigint_and_exponent`. The new code takes a different approach to the encoding. I've specifically broken the code into a `From` impl to make it easier for us to test the output. There was an impedence mismatch in the old code. Ultimately the way `BigDecimal` is represented is as a `BigInteger` with a scale. The way we're transmitting it is as a `BigInteger` with a weight and scale. Splitting it into separate integral and fractional parts, and applying different logic was making the code difficult to understand, and introducing unneccessary complications. There are two differences to how `BigUint` is represented vs how PG wants it. The first is that PG is base 10000, while `BigUint` is base 2^16. The second is that in `BigUint`, `scale` represents both the number of significant digits, *and* the position of the decimal point. In PG, `scale` only represents the number of significant digits, and there is a separate `weight` to represent the position of the decimal point. This means that `BigUint` will store trailing zeroes that we need to strip, but PG will need to ensure that the decimal falls on a digit boundary in base 10k. The majority of the logic here is to handle that portion. I've tried to make it as clear as possible what's going on through proper naming. Unfortunately the fairly simple code of iterating over the digits in base 10k gets drowned out by the cleanup. The code could potentially be simplified if we could easily iterate over the digits in big-endian order, but I could find an easy way to do that mathematically.
2017-08-07 20:13:32 +03:00
* When encoding a `BigDecimal` on PG, `1.0` is no longer encoded as if it were
`1`.
[bigdecimal-0.16.0]: https://crates.io/crates/bigdecimal
[range-0.16.0]: http://docs.diesel.rs/diesel/pg/types/sql_types/struct.Range.html
2017-07-12 07:09:37 +03:00
## [0.15.2] - 2017-07-28
### Fixed
* `BigDecimal` now properly encodes numbers starting with `10000` on postgres.
See [issue #1044][] for details.
[issue #1044]: https://github.com/diesel-rs/diesel/issues/1044
## [0.15.1] - 2017-07-24
* No changes to public API
## [0.15.0] - 2017-07-23
### Added
* Added support for the PG `IS DISTINCT FROM` operator
* The `ON` clause of a join can now be manually specified. See [the
docs][join-on-dsl-0.15.0] for details.
[join-on-dsl-0.15.0]: http://docs.diesel.rs/diesel/prelude/trait.JoinOnDsl.html#method.on
### Changed
* Diesel will now automatically invoke `numeric_expr!` for your columns in the
common cases. You will likely need to delete any manual invocations of this
macro.
* `Insertable` no longer treats all fields as nullable for type checking. What
this means for you is that if you had an impl like `impl
AsExpression<Nullable<SqlType>, DB> for CustomType` in your code base, you can
remove the `Nullable` portion (Unless you are using it with fields that are
actually nullable)
* Connections will now explicitly set the session time zone to UTC when the
connection is established
## [0.14.1] - 2017-07-10
### Changed
* The return type of `sum` and `avg` is now always considered to be `Nullable`,
as these functions return `NULL` when against on an empty table.
Release v0.14.0 (The one with all the joins) One of the oldest issues in Diesel was that we limited the number of tables that could appear in a single query to 2. The problem was never about having more than 2 tables, but safely and correctly proving in the type system what would and could not be selected from that join. With 0.14, that restriction has been removed. The query builder now supports joins containing an arbitrary number of tables. You may find that you need to call `enable_multi_table_joins!` for a few tables, but that need should go away in the future as specialization matures. In addition to the headline feature, this release includes support for several new datatypes (including `NUMERIC`/`DECIMAL` which has been widely requested), and other small quality of life improvements. As always, you can see [the CHANGELOG](https://github.com/diesel-rs/diesel/blob/v0.14.0/CHANGELOG.md) for the full release notes. The Road to 1.0 ------ A recent point of discussion among the core team has been what remaining blockers we have for releasing a version 1.0. The roadmap doesn't necessarily include everything that would make us "feature complete". It focuses on the set of changes that we think are likely to require breaking changes. We expect that this will be the last 0.x release. You can follow the milestone [here](https://github.com/diesel-rs/diesel/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.0). Additionally, we all agreed that the biggest blocker to a 1.0 release is improvements to our documentation. We're going to be doing a big push in the coming months to clean things up, and are looking for help from the community. You can follow that project [here](https://github.com/diesel-rs/diesel/projects/1), or just come join us in [our gitter room](https://gitter.im/diesel-rs/diesel?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge) to talk about how you can help. There will be a blog post with more details about this in the coming weeks. Contributors ----- In addition to the core team, 10 people contributed to this release. A huge thank you to: * Dorian Scheidt * FliegendeWurst * Georg Semmler * JD Gonzales * Jim McGrath * Kieran * Ruben De Smet * Sunrin SHIMURA (keen) * Tshepang Lekhonkhobe * theduke Core Team Changes ------ With this release, we are also making some changes to the core team to better reflect the current active maintainers. In recognition of his fantastic work, we're pleased to welcome @Eijebong to the core team. Many early members of the team have also since moved onto other projects. To reflect that, Mike Piccolo, Matt Casper, and Sam Phippen are all being moved to the core team alumni.
2017-07-04 17:56:56 +03:00
## [0.14.0] - 2017-07-04
### Added
* Added support for joining between more than two tables. The query builder can
now be used to join between any number of tables in a single query. See the
documentation for [`JoinDsl`][join-dsl-0.14.0] for details
[join-dsl-0.14.0]: http://docs.diesel.rs/diesel/prelude/trait.JoinDsl.html
* Added support for the [PostgreSQL network types][pg-network-0.14.0] `MACADDR`.
2017-05-29 08:55:59 +03:00
2017-06-21 14:51:43 +03:00
* Added support for the Numeric datatypes, using the [BigDecimal crate][bigdecimal-0.14.0].
* Added a function which maps to SQL `NOT`. See [the docs][not-0.14.0] for more
details.
* Added the [`insert_default_values`][insert-default-0.14.0] function.
[pg-network-0.14.0]: https://www.postgresql.org/docs/9.6/static/datatype-net-types.html
[not-0.14.0]: http://docs.diesel.rs/diesel/expression/dsl/fn.not.html
2017-07-13 09:30:30 +03:00
[insert-default-0.14.0]: http://docs.diesel.rs/diesel/fn.insert_default_values.html
2017-07-04 19:05:50 +03:00
[bigdecimal-0.14.0]: https://crates.io/crates/bigdecimal
Refactor `infix_predicate!`, add a prefix version I've refactored `infix_predicate!` and `postfix_predicate!` to share nearly all of their code, and added a prefix version. I've moved `not` to use the generated operator, and renamed all of these to names I'm comfortable with for 1.0. I want a `diesel_` prefix since these aren't likely to be called from user code much, only plugins. I like `operator` better here, since it's not a predicate if the return type is something other than bool, and it's not an expression if the return type is (). As a result of this change, `diesel_postfix_operator!` (previously `postfix_predicate!`) gained all the functionality it was missing that the infix form has (specifically, the ability to specify a backend). Most of the macro was actually extremely easy to share. The only difference between `infix_predicate_body` and `postfix_predicate_body!` for most of the code was the number of type parameters, and the names of the fields. This is easily solved with macro repeaters. The two main places where the code had to differ I've moved to seprate submacros. The first was the behavior of the body of `walk_ast`, which needed to change based on whether it was prefix, postfix, or infix. Secondly, if we're generating the `QueryFragment` impl for a specific backend rather than all backends, we need to generate a second impl for the `Debug` backend as well. Both of these were pretty easy to solve. The resulting code is perhaps a bit more gnarly if you're not used to macros, but I think it's better composed than the `global_infix_predicate_to_sql!` stuff we had before.
2017-06-11 15:24:42 +03:00
* Added `diesel_prefix_operator!` which behaves identically to
`diesel_postfix_operator!` (previously `postfix_predicate!`), but for
operators like `NOT` which use prefix notation.
### Changed
* `infix_predicate!` and `infix_expression!` have been renamed to
`diesel_infix_operator!`.
* `postfix_predicate!` and `postfix_expression!` have been renamed to
`diesel_postfix_operator!`.
Refactor `LoadDsl` to make it easier to introduce the raw SQL API One of the things that's going to make our upcoming raw SQL escape hatch different from our current `sql` function is that it's not going to require specifying the SQL type fo the query, and it's going to load parameters by name instead of by index. This does mean that we'll need to provide a parallel trait to `Queryable`, but I'd prefer to avoid introducing a parallel version of `LoadDsl`. So in order to make the type we will introduce for this compatible with `LoadDsl`, we needed to remove all mentions of `Queryable` from the trait itself, and move it to bounds on the impl instead. This means we need a new trait that is generic over the type we're deserializing, and changed `LoadDsl` to entirely base its bounds on that. I've opted for the name `LoadQuery` instead of something like `InternalLoadDsl`, as this trait is one that may end up in bounds for user code, and will certainly show up in error messages. I had to keep a bunch of redundant bounds on `LoadDsl` in order to make the impls of `SaveChangesDsl` remain disjoint. This is because associated types are basically ignored for purposes of disjointness. While we know that `Update<T, T>: !LoadQuery<SqliteConnection, U>`, since there is that second unconstrained type parameter, we cannot use `LoadQuery` for disjointness either since someone could in theory write a blanket impl of `impl<T, Conn> LoadQuery<Conn, MyType> for T` (possibly slightly more specific than that). Finally, as some bits for clarity, I've moved `Connection#query_one` over to `LoadDsl`, since it had no real reason to exist on the connection. I've renamed `query_all` to `query_by_index`, since that's how it will differ from other methods starting with `query_`. Finally, I've moved `LoadDsl#first` off to its own trait, since the bounds are verbose to write if you wanted to call `.first` otherwise.
2017-06-09 16:36:33 +03:00
* Trait bounds along the lines of `T: LoadDsl<Conn>, U: Queryable<T::SqlType,
Conn::Backend>` should be changed to `T: LoadQuery<Conn, U>`.
* Diesel now uses a migration to set up its timestamp helpers. To generate this
migration for your project, run `diesel database setup`.
Remove `#[has_many]`, it has become useless This attribute was originally required back when we were generating brute force impls of `SelectableExpression` for every column on both sides of a join. That went away a few versions back, and this attribute became mostly useless (in 0.13 you can do `child.joins(parent)` with just `BelongsTo`, but `parent.joins(child)` requires the `has_many`). One accidental side effect of how I implemented multi-table joins was that the `has_many` became mandatory again. This was very unfortunate (and means that 0.14 will generate really confusing error messages during the upgrade) so I've just gone ahead and removed it entirely. I expected this to be a lot simpler than it actually was. The problem is that `#[belongs_to]` does not directly have access to the parent table. The only way it can access it is by doing `<User as HasTable>::Table`. Even though that is a fully monomorphic projection on a local type, where the result is also a local type, Rust does not currently consider this to be a local type (I think this might be a bug or oversight). So to work around this, we instead implement the child to parent join twice, wrapping the parent table in a marker struct for the second impl. We then have blanket impls for every table that look for this marker, and generate the inverse impl that we actually want. It's a kludge, but ultimately an invisible one. The blanket impls need to be in the generated code for tables and not in Diesel core, since if you replace the parameter to `PleaseGenerateInverseJoinImpls` with a type parameter, Rust will start checking infinitely recursive forms of `PleaseGenerateInverseJoinImpls<PleaseGenerateInverseJoinImpls<...>>` whenever a projection on that parameter is evaluated. The problem with the impls being in the generated code is that downstream crates cannot rely on the fact that `SelectStatement` and friends are not tables. This was resolved by simply not having a `Table` constraint, which lets us remove a bunch of impls in Diesel core instead.
2017-06-11 19:18:13 +03:00
### Removed
* `#[has_many]` has been removed. Its functionality is now provided by
`#[belongs_to]` on the child struct. If there is no child struct to
put `#[belongs_to]` on, you can invoke `joinable!` directly instead.
## [0.13.0] - 2017-05-15
2017-04-17 05:12:20 +03:00
### Added
* Added support for chrono types with SQLite.
* Bind values can now be supplied to queries constructed using raw SQL. See [the
docs][sql-bind-0.13.0] for more details.
[sql-bind-0.13.0]: http://docs.diesel.rs/diesel/expression/sql_literal/struct.SqlLiteral.html#method.bind
* Added support for the [PostgreSQL network types][pg-network-0.13.0] `CIDR` and
`INET`.
2017-05-11 17:41:33 +03:00
[pg-network-0.13.0]: https://www.postgresql.org/docs/9.6/static/datatype-net-types.html
* Added support for `ILIKE` in PostgreSQL.
2017-05-15 19:49:26 +03:00
* `diesel migration list` will show all migrations, marking those that have been
run.
2017-04-17 05:12:20 +03:00
2017-05-15 19:49:26 +03:00
* `diesel migration pending` will list any migrations which have not been run.
2017-05-15 19:49:26 +03:00
* Added support for numeric operations with nullable types.
2017-05-15 19:49:26 +03:00
* Added [`migrations::any_pending_migrations`][pending-migrations-0.13.0].
2017-05-15 19:49:26 +03:00
[pending-migrations-0.13.0]: http://docs.diesel.rs/diesel/migrations/fn.any_pending_migrations.html
2017-04-21 00:05:08 +03:00
### Fixed
2017-05-15 19:49:26 +03:00
* Diesel CLI now respects the `--migration-dir` argument or the
`MIGRATION_DIRECTORY` environment variable for all commands.
2017-05-15 19:49:26 +03:00
* Diesel CLI now properly escapes the database name.
## [0.12.1] - 2017-05-07
### Changed
* Locked the chrono dependency to require exactly `0.3.0` instead of a semver
restriction. This restriction is required for the 0.12 line of releases to
continue compiling, as the chrono project is including breaking changes in
patch releases.
## [0.12.0] - 2017-03-16
### Added
* Added support for the majority of PG upsert (`INSERT ON CONFLICT`). We now
support specifying the constraint, as well as `DO UPDATE` in addition to `DO
NOTHING`. See [the module docs][upsert-0.12.0] for details.
[upsert-0.12.0]: http://docs.diesel.rs/diesel/pg/upsert/index.html
* Added support for the SQL concatenation operator `||`. See [the docs for
2017-03-04 18:56:55 +03:00
`.concat`][concat-0.12.0] for more details.
[concat-0.12.0]: http://docs.diesel.rs/diesel/expression/expression_methods/text_expression_methods/trait.TextExpressionMethods.html#method.concat
2017-03-04 18:56:55 +03:00
* Added support for the PostgreSQL [`Money` type][pg-money-0.12.0].
[pg-money-0.12.0]: https://www.postgresql.org/docs/9.6/static/datatype-money.html
* Diesel CLI: Added `db` as an alias for `database`, so you can now write `diesel db setup` (which is almost 40% faster!).
* The `table!` macro now allows you to use types from crates outside of Diesel.
You can specify where types should be imported from by doing: `table! { use
some_modules::*; foo { columns... }`. Not specifying any any modules is
equivalent to `use diesel::types::*;`.
### Fixed
* `diesel_codegen` will provide a more useful error message when it encounters
an unsupported type that contains a space in MySQL.
* `#[derive(AsChangeset)]` will now respect custom `#[primary_key]` annotations,
and avoid setting those columns.
### Removed
* `WithDsl` and `Aliased` have been removed. They were a feature that was
actually closer to a cross join than the names implied, and wasn't fully
thought out. The functionality they provided will return as joins are further
revamped.
* The internal use macro `select_column_workaround!` has been removed. If you
were relying on this internal macro, you can simply delete the line that was
calling it.
2017-02-27 04:10:46 +03:00
* Columns from the right side of a left join will now need to have `.nullable()`
explicitly called to be passed to `.select`. This allows it to compose better
with functions that don't normally take nullable columns (e.g.
`lower(name).nullable()`).
## [0.11.4] - 2017-02-21
### Fixed
* Corrected a memory safety violation when using MySQL.
## 0.11.3 - 2017-02-21
* No changes
## [0.11.2] - 2017-02-19
### Changed
* `pq-sys` and `mysqlclient-sys` will no longer attempt to generate bindings at
compile time. Generating the bindings required a bleeding edge version of
clang, which caused too many issues.
## [0.11.1] - 2017-02-17
### Fixed
* `.on_conflict_do_nothing()` now interacts with slices properly.
* `MysqlConnection` now implements `Send`, which is required for connection
pooling.
Relase v0.11.0 (The one where we support MySQL) The headline features for this release are MySQL support and limited PG upsert support. MySQL support works exactly as you'd expect. Just add `features = ["mysql"]` to your Cargo.toml, pass a connection URL (where the scheme is `mysql://` and the path is the name of the database) to `MysqlConnection::establish` and you're off. Keep in mind that if you're following the getting started guide, MySQL does not support the `RETURNING` clause, so methods like `get_result` and `get_results` won't work. PostgreSQL upsert was a feature added in PG 9.5 and has been one of our most requested features. The full upsert API is quite complex, but we've added support for `ON CONFLICT DO NOTHING`, as this covered the highest percentage of use cases with the lowest amount of work. You can see examples in [the docs][on-conflict-do-nothing]. Support for the full upsert syntax will be coming in 0.12. In addition to the headline features, there were plenty of quality of life improvements and bug fixes. As always, you can see a full list of changes by reading [the changelog][changelog]. [on-conflict-do-nothing]: http://docs.diesel.rs/diesel/pg/upsert/trait.OnConflictExtension.html#method.on_conflict_do_nothing [changelog]: https://github.com/diesel-rs/diesel/blob/v0.11.0/CHANGELOG.md In addition to the Diesel core team, 6 additional contributors worked on this release. A huge thank you to: - Brandon W Maister - Eijebong - Georg Semmler - Jimmy Cuadra - Jovansonlee Cesar - jacob I'd also like to thank everybody who helped this release by opening issues, finding bugs, and asking/answering questions in our gitter room.
2017-02-16 22:49:59 +03:00
## [0.11.0] - 2017-02-16
### Added
* Added support for MySQL as an additional backend. Diesel CLI will install with
MySQL support by default. To enable it for Diesel and Diesel Codegen, add
2017-02-16 22:33:18 +03:00
`features = ["mysql"]` to Cargo.toml. See [the docs][mysql-0.11.0] for details.
[mysql-0.11.0]: http://docs.diesel.rs/diesel/mysql/index.html
* Added support for PG's `ON CONFLICT DO NOTHING` clause. See [the
docs][on-conflict-0.11.0] for details.
[on-conflict-0.11.0]: http://docs.diesel.rs/diesel/pg/upsert/trait.OnConflictExtension.html#method.on_conflict_do_nothing
* Queries constructed using [`diesel::select`][select-0.11.0] now work properly
when [boxed][boxed-0.11.0].
Relase v0.11.0 (The one where we support MySQL) The headline features for this release are MySQL support and limited PG upsert support. MySQL support works exactly as you'd expect. Just add `features = ["mysql"]` to your Cargo.toml, pass a connection URL (where the scheme is `mysql://` and the path is the name of the database) to `MysqlConnection::establish` and you're off. Keep in mind that if you're following the getting started guide, MySQL does not support the `RETURNING` clause, so methods like `get_result` and `get_results` won't work. PostgreSQL upsert was a feature added in PG 9.5 and has been one of our most requested features. The full upsert API is quite complex, but we've added support for `ON CONFLICT DO NOTHING`, as this covered the highest percentage of use cases with the lowest amount of work. You can see examples in [the docs][on-conflict-do-nothing]. Support for the full upsert syntax will be coming in 0.12. In addition to the headline features, there were plenty of quality of life improvements and bug fixes. As always, you can see a full list of changes by reading [the changelog][changelog]. [on-conflict-do-nothing]: http://docs.diesel.rs/diesel/pg/upsert/trait.OnConflictExtension.html#method.on_conflict_do_nothing [changelog]: https://github.com/diesel-rs/diesel/blob/v0.11.0/CHANGELOG.md In addition to the Diesel core team, 6 additional contributors worked on this release. A huge thank you to: - Brandon W Maister - Eijebong - Georg Semmler - Jimmy Cuadra - Jovansonlee Cesar - jacob I'd also like to thank everybody who helped this release by opening issues, finding bugs, and asking/answering questions in our gitter room.
2017-02-16 22:49:59 +03:00
[select-0.11.0]: https://docs.rs/diesel/0.11.0/diesel/fn.select.html
[boxed-0.11.0]: http://docs.rs/diesel/0.11.0/prelude/trait.BoxedDsl.html
2017-02-13 17:41:37 +03:00
* Arrays containing null are now supported. `infer_schema!` will never infer an
array that contains null, but a `table!` definition which specifies a type of
`Array<Nullable<X>>` can now be deserialized to `Vec<Option<T>>`
* [`#[belongs_to]`][belongs-to-0.11.0] associations can now be self referential.
This will generate the code required for
[`belonging_to`][belonging-to-0.11.0], without generating code for performing
a join.
Relase v0.11.0 (The one where we support MySQL) The headline features for this release are MySQL support and limited PG upsert support. MySQL support works exactly as you'd expect. Just add `features = ["mysql"]` to your Cargo.toml, pass a connection URL (where the scheme is `mysql://` and the path is the name of the database) to `MysqlConnection::establish` and you're off. Keep in mind that if you're following the getting started guide, MySQL does not support the `RETURNING` clause, so methods like `get_result` and `get_results` won't work. PostgreSQL upsert was a feature added in PG 9.5 and has been one of our most requested features. The full upsert API is quite complex, but we've added support for `ON CONFLICT DO NOTHING`, as this covered the highest percentage of use cases with the lowest amount of work. You can see examples in [the docs][on-conflict-do-nothing]. Support for the full upsert syntax will be coming in 0.12. In addition to the headline features, there were plenty of quality of life improvements and bug fixes. As always, you can see a full list of changes by reading [the changelog][changelog]. [on-conflict-do-nothing]: http://docs.diesel.rs/diesel/pg/upsert/trait.OnConflictExtension.html#method.on_conflict_do_nothing [changelog]: https://github.com/diesel-rs/diesel/blob/v0.11.0/CHANGELOG.md In addition to the Diesel core team, 6 additional contributors worked on this release. A huge thank you to: - Brandon W Maister - Eijebong - Georg Semmler - Jimmy Cuadra - Jovansonlee Cesar - jacob I'd also like to thank everybody who helped this release by opening issues, finding bugs, and asking/answering questions in our gitter room.
2017-02-16 22:49:59 +03:00
[belongs-to-0.11.0]: https://docs.rs/diesel/0.11.0/diesel/associations/trait.BelongsTo.html
[belonging-to-0.11.0]: https://docs.rs/diesel/0.11.0/diesel/prelude/trait.BelongingToDsl.html#tymethod.belonging_to
* Added support for the `rust-lang-deprecated/time` crate on PostgreSQL. To use
it, add `features = ["deprecated-time"]`
### Changed
* It is no longer possible to exhaustively match against
`result::ConnectionError`.
2017-02-07 02:06:26 +03:00
* Updated chrono to version 0.3.
* [`max`][max-0.11.0] and [`min`][min-0.11.0] are now always nullable. The database will
return `NULL` when the table is empty.
[max-0.11.0]: http://docs.diesel.rs/diesel/expression/dsl/fn.max.html
[min-0.11.0]: http://docs.diesel.rs/diesel/expression/dsl/fn.min.html
* [`now`][now-0.11.0] can now be used as an expression of type `Timestamptz`.
[now-0.11.0]: http://docs.diesel.rs/diesel/expression/dsl/struct.now.html
* [`Connection::transaction`][transaction-0.11.0] now returns your error
directly instead of wrapping it in `TransactionError`. It requires that the
error implement `From<diesel::result::Error>`
[transaction-0.11.0]: http://docs.diesel.rs/diesel/connection/trait.Connection.html#method.transaction
Use associated types for `SelectableExpression` The `SelectableExpression` trait serves two purposes for us. The first and most important role it fills is to ensure that columns from tables that aren't in the from clause cannot be used. The second way that we use it to make columns which are on the right side of a left outer join be nullable. There were two reasons that we used a type parameter instead of an associated type. The first was to make it so that `(Nullable<X>, Nullable<Y>)` could be treated as `Nullable<(X, Y)>`. We did this because the return type of `users.left_outer_join(posts)` should be `(User, Option<Post>)`, not `(User, Post)` where every field of `Post` is an `Option`. Since we now provide a `.nullable()` method in the core DSL, I think we can simply require calling that method explicitly if you want that tuple conversion to occur. I think that the most common time that conversion will even be used is when the default select clause is used, where we can just handle it for our users automatically. The other reason that we went with a type parameter originally was that it was easier, since we can provide a default value for a type parameter but not an associated type. This turned out to actually be a drawback, as it led to #104. This PR actually brings back aspects of that issue, which I'll get to in a moment. It's expected that any expression which implements `SelectableExpression<QS>` have a `T: SelectableExpression<QS>` bound for each of its parts. The problem is, the missing second parameter is defaulting to `T::SqlType`, which means we are implicitly saying that this bound only applies for `QS` which does not change the SQL type (anything except a left outer join). This ultimately led to #621. However, with our current structure, it is impossible to fix #621 without re-introducing at least some aspects of #104. In https://github.com/diesel-rs/diesel/issues/104#issuecomment-172281522 I said that we didn't need to worry about `1 + NULL`, because we didn't implement add for any nullable types. However, I'm not sure I considered joins when I made that statement. The statement applied to joins previously because of that implicit "sql type doesn't change" constraint. This commit removes that constraint, meaning #104 will be back at least when the nullability comes from being on the right side of a left join. I don't think this is a serious enough issue that we need to immediately address it, as the types of queries which would cause the issue still just don't happen in practice. We should come up with a long term plan for it, though. Ultimately the nullability of a field really only matters in the select clause. Since any operation on null returns null, and you basically want null to act as false in the where clasue, it doesn't matter there. So one partial step we could take is to break this out into two separate traits. One for the "make sure this is valid given the from clause", and one for the "make this nullable sometimes" case and only constrain on the first one in the where clause. We could then re-add the "sql type doesn't change" constraint on the problem cases, which will bring back aspects of #621, but only for select clauses which is a smaller problem. I'm not sure if I ultimately want to go the two traits route or not. If nothing else, the problem cases are much more obvious with this commit. Anywhere that has `type SqlTypeForSelect = Self::SqlType` is likely a problem case when joins are involved. This will make it easier to find all the places to apply a solution when I come up with one that I'm happy with. Fixes #621.
2017-02-15 15:28:24 +03:00
* The way tuples of columns from the right side of left outer joins interact
with `.select` has changed. If you are deserializing into an option of a tuple
(instead of a tuple of options), you will need to explicitly call
`.nullable()`. (e.g. `.select(users::name, (posts::title,
posts::body).nullable())`)
### Removed
* `result::TransactionError`
* `result::TransactionResult`
## [0.10.1] - 2017-02-08
### Fixed
* `infer_table_from_schema!` properly handles table names with a custom schema
specified.
### Changed
2017-02-07 14:08:55 +03:00
* Updated uuid to version 0.4.
Release v0.10.0 (The one where we work on stable) ![It's happening](http://i.imgur.com/7drHiqr.gif) v0.10.0 drops support for Rust 1.14 and earlier, and adds support for Rust 1.15 (ON STABLE). `diesel_codegen_syntex` has been removed, and is no longer supported. Additionally, this release adds initial support for the JSON data type in PostgreSQL. There is also a new `print-schema` subcommand in Diesel CLI which will show you the code generated by `infer_schema!()`. As always, you can find a full list of what has changed in [the changelog][changelog]. In addition to the Diesel core team, 7 contributors worked on this release. A huge thank you to - Adrian Perez de Castro - Eric Kidd - Georg Semmler - Jake Goulding - Sergio Benitez - Severen Redwood - Stu Black I'd also like to thank everybody who helped this release by opening issues, finding bugs, and asking/answering questions in our gitter room. There were several big features that I had hoped to get done in time for this release, but my daughter inherited my troll gene and decided to come early. If you were hoping for MySQL support, blame Ruby. In the mean time, here is a picture of Ruby. ![baby ruby](https://lh3.googleusercontent.com/7vUZONdvrati-NQXriSqzKQ0CHNz6KRulOSos9kJjzMNV-JI2UT6d4Kxex9fZGO-0GTlLrKHKRwiPaf2v6hCJlCU0IgK5kWd_JWz9nG61FrZfgVARZEqXOmjoXPb5CYrbTg7XlG2VEYlcm6_Lk9oviVPh7mx3gaXgVG6g-OJRHqY_gipU-Y2REPFDoJyPWZ9QoifZH1WDGSPdyYUQ1KWeTfFkxk1Z3VP1bKAyRhsDmnXvSLaWkBQ6r5CpRS2pfVMC0lPVAfPGmrjwmNw7JmFNfscQM5IY0FOqbbwJhPJvLtNb-jOgOQhz07S8HA9BBI_cWzzXXMxbGXzaPpKBYSrioMja3MkXcb1PGB8cG7ERtG_CWwpGriRlFbrj2B0OygkAu4Q6pRiQe6BojpHYp03uyRsmsVxTbQjlH3axed6tNV_IDYSd2vz15gB7yFKUF_Je3spUUdexLmybdPDR29DfD-hBBJfezy0gdzrf7dJMMXWgQ7CW6jH18uydl-iiK3_8Ha8FUuvrjcA-Dvv0nQEXqajcb_NFCpobr92fNQvDCg6UNj3o7E7bv55Oj6sOk7N7xARchy-MmAV8Tzzc1Sx-4GKHhikH5WGMb5AzYSnoNcvWr7mD4vqAF1Wn_60Huz1KCNC5m2aBbPz9G6hBcM3pMe8J5pIM4epvKFvKUKtK98=w792-h1056-no) [changelog]: https://github.com/diesel-rs/diesel/blob/v0.10.0/CHANGELOG.md
2017-02-02 21:17:47 +03:00
## [0.10.0] - 2017-02-02
### Added
* Added support for the PostgreSQL [`json` and `jsonb` types][pg-json]. They can
be mapped to/from `serde_json::Value`. The `serde` feature must be enabled to
use the JSON types.
[pg-json]: https://www.postgresql.org/docs/9.6/static/datatype-json.html
* Added the `print-schema` command to Diesel CLI. This command will print the
output of the `infer_schema!` macro. For more information run `diesel help
print-schema`.
### Changed
* When possible, we will use deprecation warnings for breaking changes.
Deprecated code requires the `with-deprecated` feature, which is enabled by
default.
* The `postgres` feature is no longer enabled by default by `diesel` or
`diesel_codegen_syntex`. Add `features = ["postgres"]` to your `Cargo.toml`.
* The `persistable` module has been renamed to `insertable`.
### Fixed
* `#[derive(Insertable)]` allows fields of type `Option<T>` to be used with
columns that are not null if they have a default value.
### Removed
* `diesel_codegen_syntex` is no longer supported. `diesel_codegen` can now be
used on stable Rust.
* Dropped support for Rust 1.14 and earlier
## [0.9.1] - 2016-12-09
### Fixed
* Added missing impls for loading `chrono::NaiveDateTime` from a column of type
`Timestamptz`
* `#[derive(AsChangeset)]` no longer assumes that `use diesel::prelude::*` has
been done.
* `debug_sql!` can now properly be used with types from `chrono` or
`std::time`.
Construct error messages properly when libpq returns `NULL` result I had originally thought that this was some weird condition that was the result of the server getting a query with more than `34464` (`i16::MAX`) bind parameters, where we got back an error but it had no message. We panic in that case, as PG is documented that all errors have a message. It turns out I was wrong for two reasons. First, the number is 65535 (`u16::MAX`), not `34464`. (This might have been something changed on the PG side in 9.6 which was released since I last looked at this). Second, we were not getting back an error with no message, we were getting a `NULL` return value from libpq. From [their docs][]: [their docs]: https://www.postgresql.org/docs/9.6/static/libpq-exec.html#LIBPQ-PQPREPARE > A null result indicates out-of-memory or inability to send the command > at all. Use PQerrorMessage to get more information about such errors. `PQerrorMessage` means the error is on the connection. The reason that we had no result was that the PG wire protocol uses a `u16` for the number of bind parameters, so there's no way for the driver to have even sent the message to the server. Once we realized the error condition that we were seeing is more general than just the bind parameter case, I've refactored the code to perform a not null check as early as possible, and hide the `*mut PGresult`. The test itself is written in a somewhat strange fashion. We're constructing a query that has 70_000 bind parameters, as this is the only case that I know of which will always cause libpq to return null. I don't care what the error message is, just that it's not an empty string. I've also written the test to explicitly match instead of unwrap and use `#[should_panic]` because I want to be sure that it *didn't* panic. Ideally we would never see `*mut PGresult` anywhere in the code, and use `Unique<PGresult>` instead. However, it is currently unstable. I had originally implemented this to use `Unique` if `feature = "unstable"` was set, but deleted it as the `#[cfg]` branches made the code harder to comprehend. The only real benefit `Unique` gives us here is clarity of intent. For the not-null and non-aliased hints to result in any optimization by the compiler would require libpq to be statically linked, and LTO to be happening at the LLVM layer, neither of which are commonly true. We know that `Send` and `Sync` are safe to implement on our new struct, because the pointer is unaliased. We can delete those impls if we switch to using `Unique` in the future, as it already implements those traits. Fixes #446.
2016-12-10 15:19:18 +03:00
* When using PostgreSQL, attempting to get the error message of a query which
could not be transmitted to the server (such as a query with greater than
65535 bind parameters) will no longer panic.
## [0.9.0] - 2016-12-08
2016-12-02 23:41:53 +03:00
### Added
* Added support for SQL `NOT IN` using the `ne_any` method.
* The `table!` macro now allows custom schemas to be specified. Example:
```rust
table! {
schema_1.table_1 {
id -> Integer,
}
}
```
The generated module will still be called `table_1`.
* The `infer_table_from_schema!` macro now allows custom schemas to be
specified. Example:
```rust
infer_table_from_schema!("dotenv:DATABASE_URL", "schema_1.table_1");
```
* The `infer_schema!` optionally allows a schema name as the second argument. Any
schemas other than `public` will be wrapped in a module with the same name as
the schema. For example, `schema_1.table_1` would be referenced as
`schema_1::table_1`.
* Added support for batch insert on SQLite. This means that you can now pass a
slice or vector to [`diesel::insert`][insert] on all backends.
[insert]: http://docs.diesel.rs/diesel/fn.insert.html
* Added a function for SQL `EXISTS` expressions. See
[`diesel::expression::dsl::exists`][exists] for details.
[exists]: http://docs.diesel.rs/diesel/expression/dsl/fn.sql.html
* `#[derive(Identifiable)]` can be used with structs that have primary keys
other than `id`, as well as structs with composite primary keys. You can now
annotate the struct with `#[primary_key(nonstandard)]` or `#[primary_key(foo,
bar)]`.
### Changed
* All macros with the same name as traits we can derive (e.g. `Queryable!`) have
been renamed to `impl_Queryable!` or similar.
### Fixed
* `#[derive(Identifiable)]` now works on structs with lifetimes
* Attempting to insert an empty slice will no longer panic. It does not execute
any queries, but the result will indicate that we successfully inserted 0
rows.
* Attempting to update a record with no changes will no longer generate invalid
SQL. The result of attempting to execute the query will still be an error, but
but it will be a `Error::QueryBuilderError`, rather than a database error.
This means that it will not abort the current transaction, and can be handled
by applications.
* Calling `eq_any` or `ne_any` with an empty array no longer panics.
`eq_any(vec![])` will return no rows. `ne_any(vec![])` will return all rows.
## [0.8.2] - 2016-11-22
### Changed
* Fixed support for nightlies later than 2016-11-07
* Removed support for nightlies earlier than 2016-11-07
* Calls to `infer_table_from_schema!` will need to be wrapped in a module if
called more than once. This change is to work around further limitations of
the Macros 1.1 system. Example:
```rust
mod infer_users {
infer_table_from_schema!("dotenv:DATABASE_URL", "users");
}
pub use self::infer_users::*;
```
## [0.8.1] - 2016-11-01
### Added
* SQLite date and time columns can be deserialized to/from strings.
### Fixed
* Fixed an issue with `diesel_codegen` on nightlies >= 2016-10-20
## [0.8.0] - 2016-10-10
Reform types inferred by `infer_schema!` on SQLite (#277) `infer_schema!` is woefully undertested. Really our tests for it at the moment are "we use it for our test suite so the cases our suite covers work". However, even though I defined `tinyint` == `Bool`, I wanted to make sure that `TINYINT(1)` was treated as bool as well, as I wasn't certain how SQLite handles limit/precision/scale. The answer is that it doesn't, and it's way looser about allowed type names than I had thought. The process listed at https://www.sqlite.org/datatype3.html is a literal description, and any possible string is a valid type. This adds tests for every example given on that page, plus a few extras. We create a table with as many of these fields as possible, and do a trivial roundtrip to make sure that it *actually* infers something we can deserialize from, and that we're not doing anything dumb. The new logic for type inference matches pretty closely to how SQLite handles things with a few exceptions: - "boolean" or types containing "tiny" and "int" are treated as bool - smallint and bigint are separated from int - float is separated from double - varchar is separated from text - We do not accept random unrecognized type names as numeric Unresolved Questions -------------------- This actually starts to make me a bit more nervous about our semantics with SQLite. If you're just using Diesel, everything is fine. However, you can definitely insert values that would fail to deserialize with so little constraints on the backend. I'm starting to wonder if we should truly embrace SQLite's definitions and map exactly to that, allowing only the following types: - BigInt - VarChar (yes, it's the ANSI text type but we treat VarChar as the "default" string type) - Binary - Double We're omitting numeric, as there's no observable difference in SQLite between the real affinity and the numeric affinity. This would have several *major* implications. Aside from not being able to use basic things like an `i32`, it would also mean that there is no boolean type, and no dates/times/datetimes. Functions for those do exist on the SQLite side though, so some of the interactions might get super janky. That said, Diesel's goal is not to abstract away the backend. These are the semantics of the backend chosen, and maybe we should go whole hog and embrace them. I'm still unsure. In the meantime, with our current semantics, this should improve the reliability of `infer_schema!`
2016-04-17 23:42:11 +03:00
### Added
* Added partial support for composite primary keys.
2016-08-25 18:00:54 +03:00
* Added support for PostgreSQL `NULLS FIRST` and `NULLS LAST` when sorting.
See http://docs.diesel.rs/diesel/prelude/trait.SortExpressionMethods.html
for details.
* Added support for the `timestamp with time zone` type in PostgreSQL (referred
to as `diesel::types::Timestamptz`)
* Diesel CLI can now generate bash completion. See [the readme][bash completion]
for details.
* `infer_schema!` and `infer_table_from_schema!` can now take `"env:foo"`
instead of `env!("foo")` and `"dotenv:foo"` instead of `dotenv!("foo")`. The
use of `dotenv` requires the `dotenv` feature on `diesel_codegen`, which is
included by default. Using `env!` and `dotenv!` will no longer work with
`diesel_codegen`. They continue to work with `diesel_codgen_syntex`, but that
crate will be deprecated when Macros 1.1 is in the beta channel for Rust.
[bash completion]: https://github.com/diesel-rs/diesel/blob/b1a0d9901f0f2a8c8d530ccba8173b57f332b891/diesel_cli/README.md#bash-completion
### Changed
* Structs annotated with `#[has_many]` or `#[belongs_to]` now require
`#[derive(Associations)]`. This is to allow them to work with Macros 1.1.
* `embed_migrations!` now resolves paths relative to `Cargo.toml` instead of the
file the macro was called from. This change is required to allow this macro to
work with Macros 1.1.
### Fixed
* `diesel migrations run` will now respect migration directories overridden by
command line argument or environment variable
* The `infer_schema!` macro will no longer fetch views alongside with tables.
This was a source of trouble for people that had created views or are using
any extension that automatically creates views (e.g. PostGIS)
### Changed
* `#[changeset_for(foo)]` should now be written as
`#[derive(AsChangeset)] #[table_name="foo"]`. If you were specifying
`treat_none_as_null = "true"`, you should additionally have
`#[changeset_options(treat_none_as_null = "true")]`.
* `#[insertable_into(foo)]` should now be written as
`#[derive(Insertable)] #[table_name="foo"]`.
## [0.7.2] - 2016-08-20
* Updated nightly version and syntex support.
## [0.7.1] - 2016-08-11
### Changed
* The `Copy` constraint has been removed from `Identifiable::Id`, and
`Identifiable#id` now returns `&Identifiable::Id`.
### Fixed
* `#[belongs_to]` now respects the `foreign_key` option when using
`diesel_codegen` or `diesel_codegen_syntex`.
Release v0.7.0 The headline feature of this version is associations. Just add `#[belongs_to(User)]` above your struct, and it becomes incredibly easy to manipulate larger batches of data. See http://docs.diesel.rs/diesel/associations/index.html for a full guide. Diesel is taking a slightly different approach to what you may have seen in the past, which I'm calling "non-invasive associations". In contrast to something like Active Record or Ecto, where the association lives on the parent, the data is completely independent. The type of a user and all its posts is `(User, Vec<Post>)`. This release also marks the elimination of Diesel's reliance on procedural macros. They're still available as an option, and their usage is recommended. However, a lot of people have had a desire to shy away from them. For all of our code generation that does not perform IO, there is now a completely stable non-procedural macro, which has been designed to work with the [custom_derive][custom-derive] crate. See [the CHANGELOG][changelog] for a full list. [custom-derive]: https://github.com/DanielKeep/rust-custom-derive [changelog]: https://github.com/diesel-rs/diesel/blob/v0.7.0/CHANGELOG.md `diesel_codegen` has been split into two crates. This is a breaking change which will affect 100% of our users. Please see https://github.com/diesel-rs/diesel/commit/36b8801bf5e9594443743e6a7c62e29d3dce36b7 for more information on how to migrate. This release has also had a contributor who has gone above and beyond to help out. I'd like to take this opportunity to announce the 4th addition to the Diesel core team, @killercup! Your contributions have been much appreciated, and your code review has been invaluable. Thank you to everybody who contributed to this release. - derekdreery - kardeiz - Michael Macias - Mike Piccolo - Pascal Hertleif - Richard Dodd - Tim Brooks On to 0.8! With this release, we are approaching the benchmarks I had set for 1.0. We will still have at least 2 more releases before the 1.0 release, but it's quickly becoming the next target. We will be publishing a roadmap soon.
2016-08-01 22:56:01 +03:00
## [0.7.0] - 2016-08-01
Provide a syntax extension free alternative to `#[insertable_into]` (#303) Provide a syntax extension free alternative to `#[insertable_into]` This provides a pure stable alternative to the `#[insertable_into]` annotation. The intention is to change the annotation to call this macro, rather than `impl Insertable` directly. However, there are some unaddressed issues for that, and I will submit that as a separate PR to attempt to keep the PR size reasonable. The tests for this are a bit messy, as the actual test body doesn't change much -- Just the struct definition. I moved the most common case out into a macro, but I opted to just leave the duplication for the remaining 4-5 cases that didn't fit, instead of trying to make it so dry it chafes. We will continue to support syntex as an option on stable, as we can provide much better error messages from a procedural macro. I would like to improve the error messages in some cases if possible though (in particular, we want to handle the case where a unit struct is passed or where a tuple struct has unannotated fields). The structure of the macro is intended to be compatible with the `custom_derive` crate. This is untested, but will be fully tested once I've moved all our annotations to stable macros. The goal is for any struct definition to be copy pasted into this macro, and the macro parses the struct body to create the proper implementation. For sufficiently large structs, we can hit the recursion limit, but there's really no way around that. People will just need to bump the limit. One case that this macro *doesn't* handle is when there are annotations on struct fields other than `#[column_name]`. I had originally planned to handle these, but I realized that the only recognized annotation that could be there on stable is `#[cfg]`, and we are *not* handling cfg attributes. We might handle that in the future, but it'd look *really* ugly. Related to #99
2016-04-25 03:35:15 +03:00
### Added
* The initial APIs have been added in the form of `#[has_many]` and
`#[belongs_to]`. See [the module documentation][associations-module] for more
information.
Provide a syntax extension free alternative to `#[insertable_into]` (#303) Provide a syntax extension free alternative to `#[insertable_into]` This provides a pure stable alternative to the `#[insertable_into]` annotation. The intention is to change the annotation to call this macro, rather than `impl Insertable` directly. However, there are some unaddressed issues for that, and I will submit that as a separate PR to attempt to keep the PR size reasonable. The tests for this are a bit messy, as the actual test body doesn't change much -- Just the struct definition. I moved the most common case out into a macro, but I opted to just leave the duplication for the remaining 4-5 cases that didn't fit, instead of trying to make it so dry it chafes. We will continue to support syntex as an option on stable, as we can provide much better error messages from a procedural macro. I would like to improve the error messages in some cases if possible though (in particular, we want to handle the case where a unit struct is passed or where a tuple struct has unannotated fields). The structure of the macro is intended to be compatible with the `custom_derive` crate. This is untested, but will be fully tested once I've moved all our annotations to stable macros. The goal is for any struct definition to be copy pasted into this macro, and the macro parses the struct body to create the proper implementation. For sufficiently large structs, we can hit the recursion limit, but there's really no way around that. People will just need to bump the limit. One case that this macro *doesn't* handle is when there are annotations on struct fields other than `#[column_name]`. I had originally planned to handle these, but I realized that the only recognized annotation that could be there on stable is `#[cfg]`, and we are *not* handling cfg attributes. We might handle that in the future, but it'd look *really* ugly. Related to #99
2016-04-25 03:35:15 +03:00
* The `Insertable!` macro can now be used instead of `#[insertable_into]` for
those wishing to avoid syntax extensions from `diesel_codegen`. See
http://docs.diesel.rs/diesel/macro.Insertable!.html for details.
* The `Queryable!` macro can now be used instead of `#[derive(Queryable)]` for
those wishing to avoid syntax extensions from `diesel_codegen`. See
http://docs.diesel.rs/diesel/macro.Queryable!.html for details.
* The `Identifiable!` macro can now be used instead of `#[derive(Identifiable)]` for
those wishing to avoid syntax extensions from `diesel_codegen`. See
http://docs.diesel.rs/diesel/macro.Identifiable!.html for details.
* The `AsChangeset!` macro can now be used instead of `#[changeset_for(table)]`
for those wishing to avoid syntax extensions from `diesel_codegen`. See
http://docs.diesel.rs/diesel/macro.AsChangeset!.html for details.
* Added support for the PostgreSQL `ALL` operator. See
http://docs.diesel.rs/diesel/pg/expression/dsl/fn.all.html for details.
* Added support for `RETURNING` expressions in `DELETE` statements. Implicitly
these queries will use `RETURNING *`.
Reform types inferred by `infer_schema!` on SQLite (#277) `infer_schema!` is woefully undertested. Really our tests for it at the moment are "we use it for our test suite so the cases our suite covers work". However, even though I defined `tinyint` == `Bool`, I wanted to make sure that `TINYINT(1)` was treated as bool as well, as I wasn't certain how SQLite handles limit/precision/scale. The answer is that it doesn't, and it's way looser about allowed type names than I had thought. The process listed at https://www.sqlite.org/datatype3.html is a literal description, and any possible string is a valid type. This adds tests for every example given on that page, plus a few extras. We create a table with as many of these fields as possible, and do a trivial roundtrip to make sure that it *actually* infers something we can deserialize from, and that we're not doing anything dumb. The new logic for type inference matches pretty closely to how SQLite handles things with a few exceptions: - "boolean" or types containing "tiny" and "int" are treated as bool - smallint and bigint are separated from int - float is separated from double - varchar is separated from text - We do not accept random unrecognized type names as numeric Unresolved Questions -------------------- This actually starts to make me a bit more nervous about our semantics with SQLite. If you're just using Diesel, everything is fine. However, you can definitely insert values that would fail to deserialize with so little constraints on the backend. I'm starting to wonder if we should truly embrace SQLite's definitions and map exactly to that, allowing only the following types: - BigInt - VarChar (yes, it's the ANSI text type but we treat VarChar as the "default" string type) - Binary - Double We're omitting numeric, as there's no observable difference in SQLite between the real affinity and the numeric affinity. This would have several *major* implications. Aside from not being able to use basic things like an `i32`, it would also mean that there is no boolean type, and no dates/times/datetimes. Functions for those do exist on the SQLite side though, so some of the interactions might get super janky. That said, Diesel's goal is not to abstract away the backend. These are the semantics of the backend chosen, and maybe we should go whole hog and embrace them. I'm still unsure. In the meantime, with our current semantics, this should improve the reliability of `infer_schema!`
2016-04-17 23:42:11 +03:00
### Changed
* Diesel now targets `nightly-2016-07-07`. Future releases will update to a
newer nightly version on the date that Rust releases.
* `diesel_codegen` has been split into two crates. `diesel_codegen` and
`diesel_codegen_syntex`. See [this commit][syntex-split] for migration
information.
* Most structs that implement `Queryable` will now also need
`#[derive(Identifiable)]`.
Reform types inferred by `infer_schema!` on SQLite (#277) `infer_schema!` is woefully undertested. Really our tests for it at the moment are "we use it for our test suite so the cases our suite covers work". However, even though I defined `tinyint` == `Bool`, I wanted to make sure that `TINYINT(1)` was treated as bool as well, as I wasn't certain how SQLite handles limit/precision/scale. The answer is that it doesn't, and it's way looser about allowed type names than I had thought. The process listed at https://www.sqlite.org/datatype3.html is a literal description, and any possible string is a valid type. This adds tests for every example given on that page, plus a few extras. We create a table with as many of these fields as possible, and do a trivial roundtrip to make sure that it *actually* infers something we can deserialize from, and that we're not doing anything dumb. The new logic for type inference matches pretty closely to how SQLite handles things with a few exceptions: - "boolean" or types containing "tiny" and "int" are treated as bool - smallint and bigint are separated from int - float is separated from double - varchar is separated from text - We do not accept random unrecognized type names as numeric Unresolved Questions -------------------- This actually starts to make me a bit more nervous about our semantics with SQLite. If you're just using Diesel, everything is fine. However, you can definitely insert values that would fail to deserialize with so little constraints on the backend. I'm starting to wonder if we should truly embrace SQLite's definitions and map exactly to that, allowing only the following types: - BigInt - VarChar (yes, it's the ANSI text type but we treat VarChar as the "default" string type) - Binary - Double We're omitting numeric, as there's no observable difference in SQLite between the real affinity and the numeric affinity. This would have several *major* implications. Aside from not being able to use basic things like an `i32`, it would also mean that there is no boolean type, and no dates/times/datetimes. Functions for those do exist on the SQLite side though, so some of the interactions might get super janky. That said, Diesel's goal is not to abstract away the backend. These are the semantics of the backend chosen, and maybe we should go whole hog and embrace them. I'm still unsure. In the meantime, with our current semantics, this should improve the reliability of `infer_schema!`
2016-04-17 23:42:11 +03:00
* `infer_schema!` on SQLite now accepts a larger range of type names
* `types::VarChar` is now an alias for `types::Text`. Most code should be
unaffected by this. PG array columns are treated slightly differently,
however. If you are using `varchar[]`, you should switch to `text[]` instead.
* Struct fields annotated with `#[column_name="name"]` should be changed to
`#[column_name(name)]`.
* The structure of `DatabaseError` has changed to hold more information. See
http://docs.diesel.rs/diesel/result/enum.Error.html and
http://docs.diesel.rs/diesel/result/trait.DatabaseErrorInformation.html for
more information
* Structs which implement `Identifiable` can now be passed to `update` and
`delete`. This means you can now write `delete(&user).execute(&connection)`
instead of `delete(users.find(user.id)).execute(&connection)`
[associations-module]: http://docs.diesel.rs/diesel/associations/index.html
[syntex-split]: https://github.com/diesel-rs/diesel/commit/36b8801bf5e9594443743e6a7c62e29d3dce36b7
### Fixed
* `&&[T]` can now be used in queries. This allows using slices with things like
`#[insertable_into]`.
## [0.6.1] 2016-04-14
### Added
* Added the `escape` method to `Like` and `NotLike`, to specify the escape
character used in the pattern. See [EscapeExpressionMethods][escape] for
details.
[escape]: http://docs.diesel.rs/diesel/expression/expression_methods/escape_expression_methods/trait.EscapeExpressionMethods.html
### Fixed
* `diesel_codegen` and `diesel_cli` now properly rely on Diesel 0.6.0. The
restriction to 0.5.0 was an oversight.
2016-04-16 17:51:55 +03:00
* `infer_schema!` now properly excludes metadata tables on SQLite.
* `infer_schema!` now properly maps types on SQLite.
## [0.6.0] 2016-04-12
### Added
* Queries can now be boxed using the `into_boxed()` method. This is useful for
conditionally modifying queries without changing the type. See
[BoxedDsl][boxed_dsl] for more details.
* `infer_schema!` is now supported for use with SQLite3.
* The maximum table size can be increased to 52 by enabling the `huge-tables`
feature. This feature will substantially increase compile times.
* The `DISTINCT` keyword can now be added to queries via the `distinct()`
method.
* `SqliteConnection` now implements `Send`
[boxed_dsl]: http://docs.diesel.rs/diesel/prelude/trait.BoxedDsl.html
### Changed
* `diesel::result::Error` now implements `Send` and `Sync`. This required a
change in the return type of `ToSql` and `FromSql` to have those bounds as
well.
* It is no longer possible to pass an owned value to `diesel::insert`. `insert`
will now give a more helpful error message when you accidentally try to pass
an owned value instead of a reference.
### Fixed
* `#[insertable_into]` can now be used with structs that have lifetimes with
names other than `'a'`.
* Tables with a single column now properly return a single element tuple. E.g.
if the column was of type integer, then `users::all_columns` is now `(id,)`
and not `id`.
* `infer_schema!` can now work with tables that have a primary key other than
`id`.
### Removed
* Removed the `no select` option for the `table!` macro. This was a niche
feature that didn't fit with Diesel's philosophies. You can write a function
that calls `select` for you if you need this functionality.
## [0.5.4] 2016-03-23
* Updated `diesel_codegen` to allow syntex versions up to 0.30.0.
2016-03-13 01:44:54 +03:00
## [0.5.3] 2016-03-12
### Added
* Added helper function `diesel_manage_updated_at('TABLE_NAME')` to postgres
upon database setup. This function sets up a trigger on the specified table
that automatically updates the `updated_at` column to the `current_timestamp`
for each affected row in `UPDATE` statements.
* Added support for explicit `RETURNING` expressions in `INSERT` and `UPDATE`
queries. Implicitly these queries will still use `RETURNING *`.
2016-03-13 01:44:54 +03:00
### Fixed
* Updated to work on nightly from early March
## [0.5.2] 2016-02-27
* Updated to work on nightly from late February
## [0.5.1] 2016-02-11
* Diesel CLI no longer has a hard dependency on SQLite and PostgreSQL. It
assumes both by default, but if you need to install on a system that doesn't
have one or the other, you can install it with `cargo install diesel_cli
--no-default-features --features postgres` or `cargo install diesel_cli
--no-default-features --features sqlite`
## [0.5.0] 2016-02-05
### Added
2016-02-03 17:02:10 +03:00
* Added support for SQLite. Diesel still uses postgres by default. To use SQLite
instead, add `default-features = false, features = ["sqlite"]` to your
2016-02-06 00:33:36 +03:00
Cargo.toml. You'll also want to add `default-features = false, features =
["sqlite"]` to `diesel_codegen`.
2016-02-03 17:02:10 +03:00
Since SQLite is a much more limited database, it does not support our full set
of features. You can use SQLite and PostgreSQL in the same project if you
desire.
* Added support for mapping `types::Timestamp`, `types::Date`, and `types::Time`
to/from `chrono::NaiveDateTime`, `chrono::NaiveDate`, and `chrono::NaiveTime`.
Add `features = ["chrono"]` to enable.
* Added a `treat_none_as_null` option to `changeset_for`. When set to `true`,
a model will set a field to `Null` when an optional struct field is `None`,
instead of skipping the field entirely. The default value of the option is
`false`, as we think the current behavior is a much more common use case.
* Added `Expression#nullable()`, to allow comparisons of not null columns with
nullable ones when required.
2016-01-30 05:27:33 +03:00
* Added `sum` and `avg` functions.
* Added the `diesel setup`, `diesel database setup`, and `diesel database
reset` commands to the CLI.
2016-02-05 23:06:44 +03:00
* Added support for SQL `IN` statements through the `eq_any` method.
2016-02-06 00:33:36 +03:00
* Added a top level `select` function for select statements with no from clause.
This is primarily intended to be used for testing Diesel itself, but it has
been added to the public API as it will likely be useful for third party
crates in the future. `select(foo).from(bar)` might be a supported API in the
future as an alternative to `bar.select(foo)`.
* Added `expression::dsl::sql` as a helper function for constructing
`SqlLiteral` nodes. This is primarily intended to be used for testing Diesel
itself, but is part of the public API as an escape hatch if our query builder
DSL proves inadequate for a specific case. Use of this function in any
production code is discouraged as it is inherently unsafe and avoids real type
checking.
### Changed
2016-02-05 23:06:44 +03:00
* Moved most of our top level trait exports into a prelude module, and
re-exported our CRUD functions from the top level.
`diesel::query_builder::update` and friends are now `diesel::update`, and you
will get them by default if you import `diesel::*`. For a less aggressive
glob, you can import `diesel::prelude::*`, which will only export our traits.
* `Connection` is now a trait instead of a struct. The struct that was
previously known as `Connection` can be found at `diesel::pg::PgConnection`.
2016-01-15 19:29:27 +03:00
* Rename both the `#[derive(Queriable)]` attribute and the `Queriable` trait to
use the correct spelling `Queryable`.
2016-02-05 23:06:44 +03:00
* `load` and `get_results` now return a `Vec<Model>` instead of an iterator.
* Replaced `Connection#find(source, id)` with
`source.find(id).first(&connection)`.
2016-02-06 00:34:45 +03:00
* The `debug_sql!` macro now uses \` for identifier quoting, and `?` for bind
parameters, which is closer to a "generic" backend. The previous behavior had
no identifier quoting, and used PG specific bind params.
Make `ToSql` and `FromSql` generic over the backend This was a mostly mechanical change, but there were several points of interest. I've done my best to audit impls which I consider generic, vs impls that are PG specific. This implies that an impl even can be considered generic. This mostly doesn't apply to SQLite, since due to the way its bind parameters are handled I don't expect that types will go through `ToSql`. `FromSql` I'm still unclear on, and that might change further. However, after reading through the `MySQL` docs for bind params, I'm reasonably confident that for string types, binary types, and numeric types which have an equivalent C primitive, they will always be represented this way. SQL standard types which I believe will generally very by backend are date/time types, and decimal. As part of this change, our blanket impl causing `FromSql` implying `FromSqlRow` becomes invalid. I won't go into too much detail here, as I've written up a pre-RFC on a solution that goes into more detail at https://internals.rust-lang.org/t/pre-rfc-sealed-traits/3108/1, and I think this issue goes away once specialization is stable (which is tracked at https://github.com/sgrif/diesel/issues/130). With this change, I believe the only remaining trait which needs to be made generic is `NativeSqlType` (though I'm legitimately unsure if we actually want to do that, due to the complications it adds with our expression heirarchy related to `Bool`, and I do not think I want `Expression` to be generic over the backend)
2016-01-24 00:28:45 +03:00
* Many user facing types are now generic over the backend. This includes, but is
not limited to `Queryable` and `Changeset`. This change should not have much
impact, as most impls will have been generated by diesel_codegen, and that API
has not changed.
* The mostly internal `NativeSqlType` has been removed. It now requires a known
backend. `fn<T> foo() where T: NativeSqlType` is now `fn<T, DB> foo() where
DB: HasSqlType<T>`
### Removed
* `Connection#query_sql` and `Connection#query_sql_params` have been removed.
These methods were not part of the public API, and were only meant to be used
for testing Diesel itself. However, they were technically callable from any
crate, so the removal has been noted here. Their usage can be replaced with
bare `select` and `expression::dsl::sql`.
2016-01-11 23:17:30 +03:00
## [0.4.1] 2016-01-11
### Changed
* Diesel CLI will no longer output notices about `__diesel_schema_migrations`
already existing.
2016-01-11 23:17:30 +03:00
* Relicensed under MIT/Apache dual
## [0.4.0] 2016-01-08
### Added
* Added Diesel CLI, a tool for managing your schema.
See [the readme](https://github.com/diesel-rs/diesel/blob/v0.4.0/README.md#database-migrations)
for more information.
* Add the ability for diesel to maintain your schema for you automatically. See
the [migrations](http://docs.diesel.rs/diesel/migrations/index.html)
module for individual methods.
* Add DebugQueryBuilder to build sql without requiring a connection.
* Add print_sql! and debug_sql! macros to print out and return sql strings from
QueryFragments.
### Fixed
* `#[changeset_for]` can now be used with structs containing a `Vec`. Fixes
[#63](https://github.com/diesel-rs/diesel/issues/63).
* No longer generate invalid SQL when an optional update field is not the first
field on a changeset. Fixes [#68](https://github.com/diesel-rs/diesel/issues/68).
* `#[changeset_for]` can now be used with structs containing only a single field
other than `id`. Fixes [#66](https://github.com/diesel-rs/diesel/issues/66).
* `infer_schema!` properly works with array columns. Fixes
[#65](https://github.com/diesel-rs/diesel/issues/65).
## [0.3.0] 2015-12-04
### Changed
* `#[changeset_for(table)]` now treats `Option` fields as an optional update.
Previously a field with `None` for the value would insert `NULL` into the
database field. It now does not update the field if the value is `None`.
* `.save_changes` (generated by `#[changeset_for]`) now returns a new struct,
rather than mutating `self`. The returned struct can be any type that
2016-01-15 19:29:27 +03:00
implements `Queryable` for the right SQL type
### Fixed
2016-01-15 19:29:27 +03:00
* `#[derive(Queryable)]` now allows generic parameters on the struct.
* Table definitions can now support up to 26 columns. Because this increases our
compile time by 3x, `features = ["large-tables"]` is needed to support table
definitions above 16 columns.
### Added
* Quickcheck is now an optional dependency. When `features = ["quickcheck"]` is
added to `Cargo.toml`, you'll gain `Arbitrary` implementations for everything
in `diesel::data_types`.
2015-12-02 18:33:36 +03:00
* Added support for the SQL `MIN` function.
* Added support for the `Numeric` data type. Since there is no Big Decimal type
in the standard library, a dumb struct has been provided which mirrors what
Postgres provides, which can be converted into whatever crate you are using.
* Timestamp columns can now be used with `std::time::SystemTime` when compiled
with `--features unstable`
2015-12-03 02:45:47 +03:00
* Implemented `Send` on `Connection` (required for R2D2 support)
* Added `infer_schema!` and `infer_table_from_schema!`. Both macros take a
database URL, and will invoke `table!` for you automatically based on the
schema. `infer_schema!` queries for the table names, while
`infer_table_from_schema!` takes a table name as the second argument.
## [0.2.0] - 2015-11-30
### Added
* Added an `execute` method to `QueryFragment`, which is intended to replace
`Connection#execute_returning_count`. The old method still exists for use
under the hood, but has been hidden from docs and is not considered public
API.
* Added `get_result` and `get_results`, which work similarly to `load` and
`first`, but are intended to make code read better when working with commands
like `create` and `update`. In the future, `get_result` may also check that
only a single row was affected.
* Added [`insert`][insert], which mirrors the pattern of `update` and `delete`.
### Changed
* Added a hidden `__Nonexhaustive` variant to `result::Error`. This is not
intended to be something you can exhaustively match on, but I do want people
to be able to check for specific cases, so `Box<std::error::Error>` is
not an option.
* `query_one`, `find`, and `first` now assume a single row is returned. For
cases where you actually expect 0 or 1 rows to be returned, the `optional`
method has been added to the result, in case having a `Result<Option<T>>` is
more ideomatic than checking for `Err(NotFound)`.
### Deprecated
* `Connection#insert` and `Connection#insert_returning_count` have been
deprecated in favor of [`insert`][insert]
## 0.1.0 - 2015-11-29
* Initial release
[0.2.0]: https://github.com/diesel-rs/diesel/compare/v0.1.0...v0.2.0
[0.3.0]: https://github.com/diesel-rs/diesel/compare/v0.2.0...v0.3.0
[0.4.0]: https://github.com/diesel-rs/diesel/compare/v0.3.0...v0.4.0
[0.4.1]: https://github.com/diesel-rs/diesel/compare/v0.4.0...v0.4.1
[0.5.0]: https://github.com/diesel-rs/diesel/compare/v0.4.1...v0.5.0
[0.5.1]: https://github.com/diesel-rs/diesel/compare/v0.5.0...v0.5.1
[0.5.2]: https://github.com/diesel-rs/diesel/compare/v0.5.1...v0.5.2
[0.5.3]: https://github.com/diesel-rs/diesel/compare/v0.5.2...v0.5.3
[0.5.4]: https://github.com/diesel-rs/diesel/compare/v0.5.3...v0.5.4
[0.6.0]: https://github.com/diesel-rs/diesel/compare/v0.5.4...v0.6.0
[0.6.1]: https://github.com/diesel-rs/diesel/compare/v0.6.0...v0.6.1
[0.7.0]: https://github.com/diesel-rs/diesel/compare/v0.6.1...v0.7.0
[0.7.1]: https://github.com/diesel-rs/diesel/compare/v0.7.0...v0.7.1
[0.7.2]: https://github.com/diesel-rs/diesel/compare/v0.7.1...v0.7.2
[0.8.0]: https://github.com/diesel-rs/diesel/compare/v0.7.2...v0.8.0
[0.8.1]: https://github.com/diesel-rs/diesel/compare/v0.8.0...v0.8.1
[0.8.2]: https://github.com/diesel-rs/diesel/compare/v0.8.1...v0.8.2
[0.9.0]: https://github.com/diesel-rs/diesel/compare/v0.8.2...v0.9.0
[0.9.1]: https://github.com/diesel-rs/diesel/compare/v0.9.0...v0.9.1
Release v0.10.0 (The one where we work on stable) ![It's happening](http://i.imgur.com/7drHiqr.gif) v0.10.0 drops support for Rust 1.14 and earlier, and adds support for Rust 1.15 (ON STABLE). `diesel_codegen_syntex` has been removed, and is no longer supported. Additionally, this release adds initial support for the JSON data type in PostgreSQL. There is also a new `print-schema` subcommand in Diesel CLI which will show you the code generated by `infer_schema!()`. As always, you can find a full list of what has changed in [the changelog][changelog]. In addition to the Diesel core team, 7 contributors worked on this release. A huge thank you to - Adrian Perez de Castro - Eric Kidd - Georg Semmler - Jake Goulding - Sergio Benitez - Severen Redwood - Stu Black I'd also like to thank everybody who helped this release by opening issues, finding bugs, and asking/answering questions in our gitter room. There were several big features that I had hoped to get done in time for this release, but my daughter inherited my troll gene and decided to come early. If you were hoping for MySQL support, blame Ruby. In the mean time, here is a picture of Ruby. ![baby ruby](https://lh3.googleusercontent.com/7vUZONdvrati-NQXriSqzKQ0CHNz6KRulOSos9kJjzMNV-JI2UT6d4Kxex9fZGO-0GTlLrKHKRwiPaf2v6hCJlCU0IgK5kWd_JWz9nG61FrZfgVARZEqXOmjoXPb5CYrbTg7XlG2VEYlcm6_Lk9oviVPh7mx3gaXgVG6g-OJRHqY_gipU-Y2REPFDoJyPWZ9QoifZH1WDGSPdyYUQ1KWeTfFkxk1Z3VP1bKAyRhsDmnXvSLaWkBQ6r5CpRS2pfVMC0lPVAfPGmrjwmNw7JmFNfscQM5IY0FOqbbwJhPJvLtNb-jOgOQhz07S8HA9BBI_cWzzXXMxbGXzaPpKBYSrioMja3MkXcb1PGB8cG7ERtG_CWwpGriRlFbrj2B0OygkAu4Q6pRiQe6BojpHYp03uyRsmsVxTbQjlH3axed6tNV_IDYSd2vz15gB7yFKUF_Je3spUUdexLmybdPDR29DfD-hBBJfezy0gdzrf7dJMMXWgQ7CW6jH18uydl-iiK3_8Ha8FUuvrjcA-Dvv0nQEXqajcb_NFCpobr92fNQvDCg6UNj3o7E7bv55Oj6sOk7N7xARchy-MmAV8Tzzc1Sx-4GKHhikH5WGMb5AzYSnoNcvWr7mD4vqAF1Wn_60Huz1KCNC5m2aBbPz9G6hBcM3pMe8J5pIM4epvKFvKUKtK98=w792-h1056-no) [changelog]: https://github.com/diesel-rs/diesel/blob/v0.10.0/CHANGELOG.md
2017-02-02 21:17:47 +03:00
[0.10.0]: https://github.com/diesel-rs/diesel/compare/v0.9.1...v0.10.0
[0.10.1]: https://github.com/diesel-rs/diesel/compare/v0.10.0...v0.10.1
Relase v0.11.0 (The one where we support MySQL) The headline features for this release are MySQL support and limited PG upsert support. MySQL support works exactly as you'd expect. Just add `features = ["mysql"]` to your Cargo.toml, pass a connection URL (where the scheme is `mysql://` and the path is the name of the database) to `MysqlConnection::establish` and you're off. Keep in mind that if you're following the getting started guide, MySQL does not support the `RETURNING` clause, so methods like `get_result` and `get_results` won't work. PostgreSQL upsert was a feature added in PG 9.5 and has been one of our most requested features. The full upsert API is quite complex, but we've added support for `ON CONFLICT DO NOTHING`, as this covered the highest percentage of use cases with the lowest amount of work. You can see examples in [the docs][on-conflict-do-nothing]. Support for the full upsert syntax will be coming in 0.12. In addition to the headline features, there were plenty of quality of life improvements and bug fixes. As always, you can see a full list of changes by reading [the changelog][changelog]. [on-conflict-do-nothing]: http://docs.diesel.rs/diesel/pg/upsert/trait.OnConflictExtension.html#method.on_conflict_do_nothing [changelog]: https://github.com/diesel-rs/diesel/blob/v0.11.0/CHANGELOG.md In addition to the Diesel core team, 6 additional contributors worked on this release. A huge thank you to: - Brandon W Maister - Eijebong - Georg Semmler - Jimmy Cuadra - Jovansonlee Cesar - jacob I'd also like to thank everybody who helped this release by opening issues, finding bugs, and asking/answering questions in our gitter room.
2017-02-16 22:49:59 +03:00
[0.11.0]: https://github.com/diesel-rs/diesel/compare/v0.10.1...v0.11.0
[0.11.1]: https://github.com/diesel-rs/diesel/compare/v0.11.0...v0.11.1
[0.11.2]: https://github.com/diesel-rs/diesel/compare/v0.11.1...v0.11.2
[0.11.4]: https://github.com/diesel-rs/diesel/compare/v0.11.2...v0.11.4
[0.12.0]: https://github.com/diesel-rs/diesel/compare/v0.11.4...v0.12.0
[0.12.1]: https://github.com/diesel-rs/diesel/compare/v0.12.0...v0.12.1
[0.13.0]: https://github.com/diesel-rs/diesel/compare/v0.12.1...v0.13.0
Release v0.14.0 (The one with all the joins) One of the oldest issues in Diesel was that we limited the number of tables that could appear in a single query to 2. The problem was never about having more than 2 tables, but safely and correctly proving in the type system what would and could not be selected from that join. With 0.14, that restriction has been removed. The query builder now supports joins containing an arbitrary number of tables. You may find that you need to call `enable_multi_table_joins!` for a few tables, but that need should go away in the future as specialization matures. In addition to the headline feature, this release includes support for several new datatypes (including `NUMERIC`/`DECIMAL` which has been widely requested), and other small quality of life improvements. As always, you can see [the CHANGELOG](https://github.com/diesel-rs/diesel/blob/v0.14.0/CHANGELOG.md) for the full release notes. The Road to 1.0 ------ A recent point of discussion among the core team has been what remaining blockers we have for releasing a version 1.0. The roadmap doesn't necessarily include everything that would make us "feature complete". It focuses on the set of changes that we think are likely to require breaking changes. We expect that this will be the last 0.x release. You can follow the milestone [here](https://github.com/diesel-rs/diesel/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.0). Additionally, we all agreed that the biggest blocker to a 1.0 release is improvements to our documentation. We're going to be doing a big push in the coming months to clean things up, and are looking for help from the community. You can follow that project [here](https://github.com/diesel-rs/diesel/projects/1), or just come join us in [our gitter room](https://gitter.im/diesel-rs/diesel?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge) to talk about how you can help. There will be a blog post with more details about this in the coming weeks. Contributors ----- In addition to the core team, 10 people contributed to this release. A huge thank you to: * Dorian Scheidt * FliegendeWurst * Georg Semmler * JD Gonzales * Jim McGrath * Kieran * Ruben De Smet * Sunrin SHIMURA (keen) * Tshepang Lekhonkhobe * theduke Core Team Changes ------ With this release, we are also making some changes to the core team to better reflect the current active maintainers. In recognition of his fantastic work, we're pleased to welcome @Eijebong to the core team. Many early members of the team have also since moved onto other projects. To reflect that, Mike Piccolo, Matt Casper, and Sam Phippen are all being moved to the core team alumni.
2017-07-04 17:56:56 +03:00
[0.14.0]: https://github.com/diesel-rs/diesel/compare/v0.13.0...v0.14.0
[0.14.1]: https://github.com/diesel-rs/diesel/compare/v0.14.0...v0.14.1
2017-07-23 12:45:18 +03:00
[0.15.0]: https://github.com/diesel-rs/diesel/compare/v0.14.1...v0.15.0
[0.15.1]: https://github.com/diesel-rs/diesel/compare/v0.15.0...v0.15.1
[0.15.2]: https://github.com/diesel-rs/diesel/compare/v0.15.1...v0.15.2