diesel-rs/diesel
1
1
Fork 0
mirror of https://github.com/diesel-rs/diesel.git synced 2024-10-04 01:28:13 +03:00
Code Issues Packages Projects Releases Wiki Activity
f370af2e3d
diesel/CHANGELOG.md

341 lines
13 KiB
Markdown
Raw Normal View History

Ensure that `Error` cannot be exhaustively matched on This is going to be the "generic thing which can fail in a myriad of ways" type. I want to be able to have specific useful cases which you can recover from (e.g. no `Box<std::error::Error>`), but I don't want people to exhaustively match on it. Techincally adding a variant to this is still a violation of [RFC #1105](https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md), but if you're actually matching against `__Nonexhaustive` and expected it not to break eventually, you knew what was coming. If some form of [RFC #757](https://github.com/rust-lang/rfcs/pull/757) ever lands, we'll switch to using that instead.
2015-11-30 00:59:46 +03:00
# 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)
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
## Unreleased
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 `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.
Implement `Queryable` as a standard non-procedural macro Queryable is fairly simple to derive compared ot some of the other cases, so the macro definition is fairly uninteresting. I needed to make some changes to the parse code to support this additional case, but I've kept those as separate commits which have more context around each change. The most surprising piece here is that we were able to make this work without requiring the `#[column_name(name)]` annotation. Due to the way that we parse the struct, the `$field_kind` variable actually acts as a fresh ident, due to macro hygiene. So even if the resulting code *looks* like it's using the same name more than once, the parser treats them as separate.
2016-05-11 22:30:27 +03:00
* 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.
Implement `#[derive(Identifiable)]` as a stable macro There are several additional cases that I'd like to handle in the future, but for this first pass it only handles cases that the procedural macro handles. It does not handle generics, tuple structs, or structs with a primary key other than ID.
2016-05-13 14:58:35 +03:00
* 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.
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
* `infer_schema!` on SQLite now accepts a larger range of type names
Change `VarChar` to be an alias to `Text` (#288) This removes the `VarChar` type entirely, unifying it with text. This simplifies the interaction with things like SQL functions, and removes gotchas like `lower` not working with text columns. SQLite will be unaffected by this change. PG is mostly unaffected. However, it doesn't treat `varchar[]` arrays as equivalent to `text[]`. INSERT and UPDATE will continue to work, but other operators/functions will error out. Since they have identical representations in the database, I'm fine with introducing the weird ideosynchracy of "use `text[]` instead of `varchar[]`, as we remove some much larger warts. There is some more in depth research/reasoning at #287. One other visible effect here is that `VarChar` can no longer be referenced in expression positions, as it is not a struct. This can be seen in the change made to `diesel_tests::schema_dsl`. Since the structs have no size and no method, there's never any reason to use them in expression positions, and I've simply replaced that field entirely. Close #287
2016-04-20 19:57:54 +03:00
* `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.
Change the format of `#[column_name]` (#301) This is entirely to support the move from syntax extensions to normal macros on stable. We cannot match the RHS of `#[column_name="name"]` and use the result in an `ident` position. We can, however, handle `#[column_name(name)]`. I prefer the old form, but it would require changes to the rust compiler to support without syntax extensions, which defeats the purpose of moving to stable.
2016-04-25 03:06:26 +03:00
* Struct fields annotated with `#[column_name="name"]` should be changed to
`#[column_name(name)]`.
Implement `AsExpression` for `&&[T]` Typically we implement this trait for `T -> ST`, `T -> Nullable<ST>`, `&T -> ST`, and `&T -> Nullable<ST>` using the `expression_impls!` macro. When the type itself is a reference, we need to do this for a double reference as well (for example, `&&str` implements `AsExpression<Text>`). The `expression_impls!` macro isn't used for array types, as it has an additional type parameter, and as such I forgot the `&&[T]` case. Fixes #308
2016-05-12 13:55:21 +03:00
### Fixed
* `&&[T]` can now be used in queries. This allows using slices with things like
`#[insertable_into]`.
Release v0.6.1 This release addresses multiple oversights from 0.6.0. The CLI and Codegen crates were incorrectly pointing at Diesel 0.5.0. Additionally, there were several major issues with `infer_schema!` on SQLite that effectively made it unusable. These have both been addressed.
2016-04-16 17:57:43 +03:00
## [0.6.1] 2016-04-14
Add the `escape` method to `Like` and `NotLike` This is functionality I need to fix a bug in diesel_codegen related to `infer_schema!` on SQLite. It felt appropriate to expose to the public API. `name.like("foo\\%").escape('\')` will generate `name LIKE 'foo\%' ESCAPE '\'` (with identifiers quoted and bind params for the strings). While `ESCAPE` isn't part of the ANSI standard, it appears to be supported by every backend, so I've left it unconstrained.
2016-04-15 20:33:48 +03:00
### 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
Add changelog entry for #274, apply to cli as well
2016-04-16 17:41:59 +03:00
### Fixed
* `diesel_codegen` and `diesel_cli` now properly rely on Diesel 0.6.0. The
restriction to 0.5.0 was an oversight.
Add a CHANGELOG entry for #271
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.
Release v0.6.0 In addition to a myriad of bug fixes, there are two headline features for this release. We now provide an API for dealing with boxed queries. Through our usage of Diesel for web apps, we found that this was a feature we needed for things like complex search forms where you may want to conditionally modify a query. For details, check out http://docs.diesel.rs/diesel/prelude/trait.BoxedDsl.html Additionally, this release fleshes out our support for SQLite by allowing the `infer_schema!` macro to be used with it. Thanks to @weiznich for working on this. There were many other changes that weren't mentioned here. For the full changelog, please see https://github.com/sgrif/diesel/blob/master/CHANGELOG.md#050-2016-04-12
2016-04-12 22:06:36 +03:00
## [0.6.0] 2016-04-12
Add helpers for managing `updated_at TIMESTAMP` columns
2016-02-01 06:42:15 +03:00
Add a changelog entry for `infer_schema!` on SQLite
2016-03-28 02:15:46 +03:00
### Added
Document boxed queries, and reference it in the change log.
2016-04-07 16:41:30 +03:00
* 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.
Add a changelog entry for `infer_schema!` on SQLite
2016-03-28 02:15:46 +03:00
* `infer_schema!` is now supported for use with SQLite3.
Bump the max table size to 52 I've put this behind another feature gate instead of just upping `large-tables`, as running `(cd diesel && cargo test --features huge-tables)` takes several minutes to compile on my machine.
2016-03-28 22:22:43 +03:00
* The maximum table size can be increased to 52 by enabling the `huge-tables`
feature. This feature will substantially increase compile times.
Add support for the `DISTINCT` keyword A few things to note about the implementation. I've opted for 2 unit structs instead of something like an enum or boolean so that the code gets inlined via monomorphisation instead of containing a branch (e.g. if you don't use distinct, it's free). As always, it's enforced that our query builder doesn't do "real work" by https://github.com/sgrif/diesel/blob/c8127d408f759faa056503014cd00e92479215e0/diesel_tests/tests/perf_details.rs#L8-L13 This ended up churning a lot of `select_dsl`. I've reformatted the code surrounding what was touched to reduce churn in the future. This doesn't yet add support for `DISTINCT ON(expr)`, as that is a PG specific feature and can be added as a separate PR. An alternative API for this would be something like `users.select(distinct(name))`. I actually think I might prefer that API, but actually enforcing correctness with it (making sure `distinct` can only be passed to `select` and not something like `filter` -- disallowing things like `max(distinct(id))`, etc) would be pretty much impossible. Fixes #253.
2016-04-02 23:05:32 +03:00
* The `DISTINCT` keyword can now be added to queries via the `distinct()`
method.
Implement `Send` for `SqliteConnection` After spending some time poking at it, I can't find any reason this wouldn't be safe. There's a legitimate use case for this where you want to share a connection to an in memory database (wrapped in a mutex of course) Fixes #228
2016-04-06 22:42:19 +03:00
* `SqliteConnection` now implements `Send`
Document boxed queries, and reference it in the change log.
2016-04-07 16:41:30 +03:00
[boxed_dsl]: http://docs.diesel.rs/diesel/prelude/trait.BoxedDsl.html
Implement `Send` and `Sync` for `Error` This required having `ToSql` and `FromSql` have these bounds, along with any traits that bubble up errors from these traits. Fixes #243.
2016-03-28 02:59:10 +03:00
### 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.
Improve the error message when `insert` is called with an owned value Prior to this commit, the error will occur when you attempt to call `execute`, `get_result`, or `get_results`. The message will indicate that those methods don't exist, because `InsertQuery` doesn't implement `QueryFragment`, with a very long generic type signature. The reason for this being that `StructName` doesn't implement `Insertable`, `&StructName` does. This now handles this common error as quickly and directly as possible. The error message will now be: ``` error: mismatched types: expected `&_` found `StructName` ``` This does cause a minor change in functionality, as it becomes impossible to pass an owned value to `insert`. I don't think this is a problem, as really the only thing this removes is the ability to construct an insert statement and the return the query without executing it, e.g.: ```rust fn build_insert_query(name: &str) -> Box<QueryFragment<Pg>> { let new_user = NewUser { name: name }; insert(new_user).into(users::table) } ``` However, this case just doesn't seem like it matters, and I'm fine with losing support for it. Fixes #249.
2016-03-31 20:25:34 +03:00
* 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.
Allow lifetime names other than `'a` with `#[insertable_into]` This implementation was left over from the days when we were using regular macros for this, and couldn't use macro variables in the positions needed. As a compiler plugin, we can support lifetimes with any name.
2016-03-31 21:18:32 +03:00
### Fixed
* `#[insertable_into]` can now be used with structs that have lifetimes with
names other than `'a'`.
Properly generate a single element tuple for 1 column tables (#262) Our code was generating `(id)` and not `(id,)`. Without the trailing comma, the parenthesis are meaningless. This meant that you couldn't actually load the query into a struct without manually selecting the tuple. While this fixes the bug, I think it probably also makes sense for us to have a `FromSqlRow` and `Queryable` impl for the non-tuple type into a single element tuple/struct. Fixes #261
2016-04-10 18:44:43 +03:00
* 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`.
Add a changelog entry for #252 [ci skip]
2016-04-12 21:28:25 +03:00
* `infer_schema!` can now work with tables that have a primary key other than
`id`.
Remove `no select` from `table!` This was something that I added to support crates.io, as their crates table has a column that's only used for querying but not ever actually selected. Ultimately this just doesn't fit with Diesel's overall philosophy. It was poorly documented and untested. Just set up an `all` function that calls `select` if you need this.
2016-04-03 01:30:01 +03:00
### 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.
Release v0.5.4 The only crate that was released was `diesel_codegen`, which contains no changes other than 24a45c9.
2016-03-24 01:25:04 +03:00
## [0.5.4] 2016-03-23
* Updated `diesel_codegen` to allow syntex versions up to 0.30.0.
Release v0.5.3
2016-03-13 01:44:54 +03:00
## [0.5.3] 2016-03-12
Add helpers for managing `updated_at TIMESTAMP` columns
2016-02-01 06:42:15 +03:00
### 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.
Implement explicit `RETURNING` for `InsertStatement` and `UpdateStatement`
2016-03-12 01:12:30 +03:00
* Added support for explicit `RETURNING` expressions in `INSERT` and `UPDATE`
queries. Implicitly these queries will still use `RETURNING *`.
Release v0.5.3
2016-03-13 01:44:54 +03:00
### Fixed
* Updated to work on nightly from early March
Release 0.5.2 of codegen There are other commits between 0.5.1 and this commit which are not being released. Codegen is the only crate being bumped.
2016-02-27 16:33:26 +03:00
## [0.5.2] 2016-02-27
* Updated to work on nightly from late February
Release v0.5.1 This is a minor release that only includes a single change to Diesel CLI. Most users can ignore this release, as it only affects users trying to install Diesel CLI on systems that don't have both SQLite and PostgreSQL installed. If you *do* need to install CLI for Postgres only, you can do so with `cargo install diesel_cli --no-default-features --features postgres`
2016-02-11 19:36:31 +03:00
## [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`
Release version 0.5.0 This is by far our biggest release yet, including 162 commits by 9 contributors. You can view the full changelog at https://github.com/sgrif/diesel/blob/v0.5.0/CHANGELOG.md To coincide with this release, we've launched a new website. Check it out at http://diesel.rs -- We've also published a new Getting Started guide. By far the biggest feature of this release is support for SQLite3 as a backend. If you'd like to try it out, add `features = ["sqlite"]` to `diesel` and `diesel_codgen` in your Cargo.toml. PostgreSQL is still included by default. To remove it, add `default-features = false`. Additionally, this release adds support for the various types from the `chrono` crate. Add `features = ["chrono"]` to enable it. Some of the more minor features include the ability to opt into the 0.2.0 behavior for updates (treating `None` as `NULL` instead of skipping the field), as well as support for the `sum` and `avg` functions. Unfortunately, there were some breaking changes in this release that are likely to have a broad impact. `diesel::Connection` is now `diesel::pg::PgConnection`. `load` and `get_results` now return a `Vec` instead of an `Iterator`. `Queriable` has been renamed to `Queryable`. This release was a huge group effort to make happen, and we hope you enjoy it. Happy Dieseling! Thank you to Diesel core team, and the contributors to this release: @oursonguimauve @robertmaloney @tamird @tessgriffin @weiznich
2016-02-06 00:36:41 +03:00
## [0.5.0] 2016-02-05
Move our types around, add a prelude module. This might move around a little bit more, but I want to just be able to write `diesel::update`, the `use` statements for those functions are really common and quite noisy. This means that we need to stop recommending glob importing the top level, and give something to be glob imported. I *think* I want to re-export the prelude from the top level, but I'm not 100% certain. An alternative would be to export some of our structs from the prelude as well. Fixes #93
2016-01-13 21:20:12 +03:00
Clean up `chrono` impl code, add tests Nothing should implement `Expression` directly. I've changed the code to only implement the traits needed, and removed the impls for time zone aware types as we should not map those to `timestamp`. We can support them when `TimestampTz` is added in the future.
2016-01-15 00:09:07 +03:00
### Added
Add a changelog entry for SQLite
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
Minor changelog edits [ci skip]
2016-02-06 00:33:36 +03:00
Cargo.toml. You'll also want to add `default-features = false, features =
["sqlite"]` to `diesel_codegen`.
Add a changelog entry for SQLite
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.
Add support for `chrono::NaiveDate` Much of this commit is from c0b0fb8. The earliest date that can be stored by postgres is J0 (November 24, 4714 BCE) and the latest that can be represented by chrono is December 31, 262143, so this is the supported range, as noted in c0b0fb8.
2016-01-19 00:00:07 +03:00
* Added support for mapping `types::Timestamp`, `types::Date`, and `types::Time`
to/from `chrono::NaiveDateTime`, `chrono::NaiveDate`, and `chrono::NaiveTime`.
Clean up `chrono` impl code, add tests Nothing should implement `Expression` directly. I've changed the code to only implement the traits needed, and removed the impls for time zone aware types as we should not map those to `timestamp`. We can support them when `TimestampTz` is added in the future.
2016-01-15 00:09:07 +03:00
Add `features = ["chrono"]` to enable.
Add `treat_none_as_null` to `changeset_for` This allows users to opt into the behavior of `changeset_for` that was present prior to #47. I still feel that the default behavior of skipping optional fields is the most common case, as explicitly wanting to set a column to `NULL` is a pretty niche case to begin with, and much more frequently the field would be `None` on the struct because you've populated it from a web form or API endpoint that doesn't specify all fields.
2016-01-19 19:51:46 +03:00
* 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.
Add `Expression#nullable` to allow comparing null and not null exprs We currently don't allow a comparison like `Eq<Integer, Nullable<Integer>>`. This is somewhat by design, but the goal was to force you to explicitly declare that you want to do this, not to make it impossible to do entirely. The `nullable` method will take a potentially nullable expression, and ensure it is of a `nullable` type. Calling it on an already `nullable` expression will not change the `SqlType` (though it will end up wrapping it in our `Nullable` expression struct). The resulting expression will have the same SQL as the original. Our private API associations have also been updated to use this new method, to allow for cases where there are optional foreign keys. Fixes #116
2016-01-20 21:06:43 +03:00
* Added `Expression#nullable()`, to allow comparisons of not null columns with
nullable ones when required.
Add a changelog entry for #144
2016-01-30 05:27:33 +03:00
* Added `sum` and `avg` functions.
Implement `diesel database reset`, and move `diesel setup` to `diesel database setup` This has a lot of changes because it does a few things at the same time: * Changed most functions to take a generic Connection. This gets us a little closer to making the CLI generic over the backend, and allows for easier testing, as it gives us control over the connection it uses. * Document more functions and add some messages to the user when running setup/reset. * Add the `diesel database reset` command, and move `diesel setup` to be a subcommand of `diesel database`.
2016-01-31 01:48:30 +03:00
* Added the `diesel setup`, `diesel database setup`, and `diesel database
reset` commands to the CLI.
Add some missing changelog entries
2016-02-05 23:06:44 +03:00
* Added support for SQL `IN` statements through the `eq_any` method.
Minor changelog edits [ci skip]
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.
Move our types around, add a prelude module. This might move around a little bit more, but I want to just be able to write `diesel::update`, the `use` statements for those functions are really common and quite noisy. This means that we need to stop recommending glob importing the top level, and give something to be glob imported. I *think* I want to re-export the prelude from the top level, but I'm not 100% certain. An alternative would be to export some of our structs from the prelude as well. Fixes #93
2016-01-13 21:20:12 +03:00
### Changed
Add some missing changelog entries
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.
Remove hard dependencies on `libpq` and `libsqlite3` All code which *directly* depends on these has been moved to a separate module and placed behind a cfg attr. There is still a ton of PG specific stuff hidden in the expressions module that simply isn't marked as such. I had to rework how we do our boilerplate type impls, as `sqlite` and `postgres` need to be able to co-exist in the same compile pass (even just for generating docs). While this PR is pretty large, it ultimately mostly comes down to clerical work. Fixes #159.
2016-02-02 21:18:51 +03:00
* `Connection` is now a trait instead of a struct. The struct that was
previously known as `Connection` can be found at `diesel::pg::PgConnection`.
Rename Queriable to Queryable
2016-01-15 19:29:27 +03:00
* Rename both the `#[derive(Queriable)]` attribute and the `Queriable` trait to
use the correct spelling `Queryable`.
Add some missing changelog entries
2016-02-05 23:06:44 +03:00
* `load` and `get_results` now return a `Vec<Model>` instead of an iterator.
Note the public API changes from #137 in the changelog
2016-01-25 07:49:06 +03:00
* Replaced `Connection#find(source, id)` with
`source.find(id).first(&connection)`.
More minor changelog edits [ci skip]
2016-02-06 00:34:45 +03:00
* The `debug_sql!` macro now uses \` for identifier quoting, and `?` for bind
Clean up the `debug_sql!` macro Some refactoring of the `PgQueryBuilder` caused a test which was using it directly to fail. The whole reason the debug query builder exists is to avoid needing to do that, so I used that macro instead. However, the macro currently requires importing the query builder, which I don't like. It was also incorrectly referencing `diesel` by name.
2016-01-22 19:23:29 +03:00
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.
Replace `NativeSqlType` with something decoupled from PG This required some changes to semi-related traits that basically boiled down to removing the `NativeSqlType` constraint unless that trait already had access to `Backend` somehow. I didn't want to make `Query` or `Expression` be generic over the backend, as this would require making all of our query DSLs generic, and type inference would no longer work. I think the new naming of `DB: HasSqlType<ST>` makes it more natural for these types not to have any constraint. As part of this, we've made it so all backends *must* at minimum handle the primitive types. This took several passes to figure out how to do properly, but I'm glad I went through the trouble, as it caught that I had accidentally implemented `ToSql` and `FromSql` for `Oid` on all backends. I've added a test to make sure the new structure still allows other crates to add new types without breaking coherence. I believe this is the last yak shave we'll need to do to make things generic over the backend (other than figuring out cli and codegen which is going to be a nightmare)
2016-01-24 20:08:51 +03:00
* 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>`
Remove `Connection#query_sql` Similar to `query_sql_params`, all uses of this function can be replaced by bare select.
2016-01-18 02:29:58 +03:00
### 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`.
Release 0.4.1
2016-01-11 23:17:30 +03:00
## [0.4.1] 2016-01-11
Don't output notices when running migrations When you run just about any command via diesel_cli, you'll see this message output to stderr. > NOTICE: relation "__diesel_schema_migrations" already exists, > skipping This silences that notice when creating the table. Unfortunately the `silence_notices` function is not necessarily idempotent, as it would override the notice processor if a custom one was set. However, the actual raw libpq connection is private, so we're free to do with it what we wish. libpq does not provide any method to get the current notice processor, or its default. As such I've had to re-implement the same function, based on the description at the bottom of http://www.postgresql.org/docs/current/static/libpq-notice-processing.html As an alternative, we could perform two queries when attempting to create the table, but this is becoming a common need in my work on new features, and might be a candidate for public API.
2016-01-09 19:42:11 +03:00
### Changed
* Diesel CLI will no longer output notices about `__diesel_schema_migrations`
already existing.
Release 0.4.1
2016-01-11 23:17:30 +03:00
* Relicensed under MIT/Apache dual
Release Diesel 0.4.0 In addition to numerous bug fixes, the headline feature of this release is the addition of Diesel CLI, and the `migrations` module to help automatically manage your schema. See the CHANGELOG for full details. https://github.com/sgrif/diesel/blob/master/CHANGELOG.md#040-2016-01-08
2016-01-09 00:48:23 +03:00
## [0.4.0] 2016-01-08
Add debugging query builder and open up public api with macros
2015-12-06 21:20:51 +03:00
### Added
Release Diesel 0.4.0 In addition to numerous bug fixes, the headline feature of this release is the addition of Diesel CLI, and the `migrations` module to help automatically manage your schema. See the CHANGELOG for full details. https://github.com/sgrif/diesel/blob/master/CHANGELOG.md#040-2016-01-08
2016-01-09 00:48:23 +03:00
* Added Diesel CLI, a tool for managing your schema.
Replace `sgrif/diesel` with `diesel-rs/diesel` in all links
2016-04-20 18:49:24 +03:00
See [the readme](https://github.com/diesel-rs/diesel/blob/v0.4.0/README.md#database-migrations)
Release Diesel 0.4.0 In addition to numerous bug fixes, the headline feature of this release is the addition of Diesel CLI, and the `migrations` module to help automatically manage your schema. See the CHANGELOG for full details. https://github.com/sgrif/diesel/blob/master/CHANGELOG.md#040-2016-01-08
2016-01-09 00:48:23 +03:00
for more information.
Document the migrations module I've also renamed `rollback` to `revert`, as I think it better expresses intent.
2016-01-07 18:35:05 +03:00
* Add the ability for diesel to maintain your schema for you automatically. See
Replace all links to the github pages site Github does *not* redirect github pages traffic when a repository is transferred to a new org. I can point the DNS to the new address, but any links that don't go somewhere on the diesel.rs domain will become dead soon.
2016-04-18 17:45:05 +03:00
the [migrations](http://docs.diesel.rs/diesel/migrations/index.html)
Document the migrations module I've also renamed `rollback` to `revert`, as I think it better expresses intent.
2016-01-07 18:35:05 +03:00
module for individual methods.
Add debugging query builder and open up public api with macros
2015-12-06 21:20:51 +03:00
* 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.
Ensure `Vec<T>` can be used in `#[changeset_for]` Usually we implement all the various `AsExpression` for refs in the `expression_impls!` macro. However, that macro doesn't work with generics, and we forgot to handle `Vec<T>` (I think I figured the slice impl was enough for some reason). I tried to write a test for this change, but there are actually several other bugs that prevent me from testing this properly. See #65 & #66. Fixes #63.
2015-12-20 21:42:17 +03:00
### Fixed
* `#[changeset_for]` can now be used with structs containing a `Vec`. Fixes
Replace `sgrif/diesel` with `diesel-rs/diesel` in all links
2016-04-20 18:49:24 +03:00
[#63](https://github.com/diesel-rs/diesel/issues/63).
Ensure `Vec<T>` can be used in `#[changeset_for]` Usually we implement all the various `AsExpression` for refs in the `expression_impls!` macro. However, that macro doesn't work with generics, and we forgot to handle `Vec<T>` (I think I figured the slice impl was enough for some reason). I tried to write a test for this change, but there are actually several other bugs that prevent me from testing this properly. See #65 & #66. Fixes #63.
2015-12-20 21:42:17 +03:00
Generate valid SQL syntax when mixing optional and non-optional updates Prior to this commit, our implementation would *never* insert a comma immediately after skipping a field. This is a problem if there was a field that was updated appearing before it. Fixes #68
2015-12-24 00:13:06 +03:00
* No longer generate invalid SQL when an optional update field is not the first
Replace `sgrif/diesel` with `diesel-rs/diesel` in all links
2016-04-20 18:49:24 +03:00
field on a changeset. Fixes [#68](https://github.com/diesel-rs/diesel/issues/68).
Generate valid SQL syntax when mixing optional and non-optional updates Prior to this commit, our implementation would *never* insert a comma immediately after skipping a field. This is a problem if there was a field that was updated appearing before it. Fixes #68
2015-12-24 00:13:06 +03:00
Fix `#[changeset_for]` with single field structs This error occurred because we were always assuming the type and body to work with tuples, and `Changeset` isn't implemented for `(A)`. We do the same workaround in the generation for `insertable_into`. I'd rather just add `(A)` to the tuple impls, but this is unfortunately impossible due to https://github.com/rust-lang/rust/issues/30762
2016-01-07 19:02:02 +03:00
* `#[changeset_for]` can now be used with structs containing only a single field
Replace `sgrif/diesel` with `diesel-rs/diesel` in all links
2016-04-20 18:49:24 +03:00
other than `id`. Fixes [#66](https://github.com/diesel-rs/diesel/issues/66).
Fix `#[changeset_for]` with single field structs This error occurred because we were always assuming the type and body to work with tuples, and `Changeset` isn't implemented for `(A)`. We do the same workaround in the generation for `insertable_into`. I'd rather just add `(A)` to the tuple impls, but this is unfortunately impossible due to https://github.com/rust-lang/rust/issues/30762
2016-01-07 19:02:02 +03:00
Infer schema properly when array columns are used Note: We don't ever actually use the added column, because we don't need to. Its presence alone is enough to cause the tests to fail. This implementation is a hack. It's awful. I need to write a more extensible system for type lookups. But right now I don't care. This is blocking 0.4, and I can fix it in 0.5. Fixes #65
2016-01-07 19:46:03 +03:00
* `infer_schema!` properly works with array columns. Fixes
Replace `sgrif/diesel` with `diesel-rs/diesel` in all links
2016-04-20 18:49:24 +03:00
[#65](https://github.com/diesel-rs/diesel/issues/65).
Infer schema properly when array columns are used Note: We don't ever actually use the added column, because we don't need to. Its presence alone is enough to cause the tests to fail. This implementation is a hack. It's awful. I need to write a more extensible system for type lookups. But right now I don't care. This is blocking 0.4, and I can fix it in 0.5. Fixes #65
2016-01-07 19:46:03 +03:00
Release 0.3.0 This is a bit of a smaller release, but I will be going on vacation for 10 days tomorrow and wanted to get some of this out before I leave. This release includes several great quality of life changes: - `#[changeset_for]` now treats `Option` as an optional update. Previously, `None` would indicate inserting NULL into a field. `None` will now be skipped in the update, better mirroring the behavior of most APIs. - `infer_schema!` and `infer_table_from_schema!` have been added, so you no longer have to manually write `table!` all over the place - Connection pooling support has been added via R2D2 This will likely be the last *super short* release, and we will probably be biweekly from now on unless there's a specific reason to break that. See you all in 10 days! 🚢 [ci skip]
2015-12-05 06:05:18 +03:00
## [0.3.0] 2015-12-04
Allow generic parameters in `#[derive(Deserialize)]` I previously didn't allow lifetimes here, as it seemed like it was not possible to return data with a lifetime. I failed to consider enums however, and reading a `Cow` is completely reasonable. Fixes #35
2015-12-01 01:32:42 +03:00
`#[changeset_for]` now skips optional fields when `None` My original thoughts on how to implement this involved boxing and sticking in a `Vec`. Unfortunately, that requires implementing `AsChangeset` for `UserChanges` and not `&UserChanges`, which I don't want to do by default. If you actually want to assign `NULL`, you can still do so by doing `update(table).set(column.eq(None))`. In the future we might introduce an additional type to make it possible to assign null through codegen. With this change in implementation, I've removed the impl of `Changeset` for `Vec<T>`, as it feels redundant with a tuple containing options. I've done a best effort to make sure we generate valid SQL in the various cases. There is still one error case, when the resulting changeset has 0 fields to update. This will be corrected in another PR, as I'm still considering whether we should do magic to return the same thing as we would otherwise, or whether it's an error case. Fixes #26
2015-12-04 20:13:56 +03:00
### 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`.
Don't mutate `self` in `save_changes` With the new behavior of `Option` in `changeset_for`, we can no longer assume that a type which implements `changeset_for` can also implement `Queriable`. I was unhappy with the API of `save_changes` anyway, as it seemed to have limited usefulness. Since I don't have a great way to conditionally implement the old form, I've simply changed it to something that we know will work for all types. If possible in the future, I might still like to default this type parameter to `Self`. Fixes #50
2015-12-05 02:11:11 +03:00
* `.save_changes` (generated by `#[changeset_for]`) now returns a new struct,
rather than mutating `self`. The returned struct can be any type that
Rename Queriable to Queryable
2016-01-15 19:29:27 +03:00
implements `Queryable` for the right SQL type
Don't mutate `self` in `save_changes` With the new behavior of `Option` in `changeset_for`, we can no longer assume that a type which implements `changeset_for` can also implement `Queriable`. I was unhappy with the API of `save_changes` anyway, as it seemed to have limited usefulness. Since I don't have a great way to conditionally implement the old form, I've simply changed it to something that we know will work for all types. If possible in the future, I might still like to default this type parameter to `Self`. Fixes #50
2015-12-05 02:11:11 +03:00
Allow generic parameters in `#[derive(Deserialize)]` I previously didn't allow lifetimes here, as it seemed like it was not possible to return data with a lifetime. I failed to consider enums however, and reading a `Cow` is completely reasonable. Fixes #35
2015-12-01 01:32:42 +03:00
### Fixed
Rename Queriable to Queryable
2016-01-15 19:29:27 +03:00
* `#[derive(Queryable)]` now allows generic parameters on the struct.
Ensure that `Error` cannot be exhaustively matched on This is going to be the "generic thing which can fail in a myriad of ways" type. I want to be able to have specific useful cases which you can recover from (e.g. no `Box<std::error::Error>`), but I don't want people to exhaustively match on it. Techincally adding a variant to this is still a violation of [RFC #1105](https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md), but if you're actually matching against `__Nonexhaustive` and expected it not to break eventually, you knew what was coming. If some form of [RFC #757](https://github.com/rust-lang/rfcs/pull/757) ever lands, we'll switch to using that instead.
2015-11-30 00:59:46 +03:00
Increase tuple impl size to 26. Arbitrarily chosen because I'd need to update my editor macro to handle more letters. This increases our compile time to 22 seconds, so it's hidden behind a feature `large-tables`. I'm unsure where the proper place to document this is. Fixes #53
2015-12-14 20:13:07 +03:00
* 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.
Clean up our quickcheck usage in tests This wasn't possible when I added these types, as our tests were still part of the same project. Now that they have their own Cargo.toml file, I can add quickcheck as an optional dependency.
2015-12-01 23:09:29 +03:00
### 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`.
Clean up the wording of the changelog
2015-12-02 18:33:36 +03:00
* Added support for the SQL `MIN` function.
Implement 'min' function based on SQLs 'MIN'
2015-12-01 22:51:22 +03:00
Add support for the Postgres numeric type This doesn't target any specific big decimal crate at the moment, it's just minimal support for columns of that type. This was pretty straightforward, the hardest part was really just getting an implementation of `Arbitrary` which matches up with the behavior of PG's reading. The `max_digits = min(weight, scale)` is incorrect, but is a rough approximation that will definitely get us below the length where it does truncation. I don't want to duplicate that logic here, as it's complex.
2015-12-02 18:31:28 +03:00
* 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.
Add support for `SystemTime` from the standard library This feature is still unstable, but I think we can manage to keep up support for it. We should point back at released quickcheck after https://github.com/BurntSushi/quickcheck/pull/110 is merged and released.
2015-12-02 22:13:12 +03:00
* 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)
I suppose the `Sync` change is worth a changelog entry
2015-12-03 02:45:03 +03:00
Add `infer_schema!`, document both this and the table specific form `infer_schema_from_table!` calls `table!` for you automatically for a single table. `infer_schema!` loads the table names from the database and calls `infer_schema_from_table!` for you automatically. Fixes #40.
2015-12-05 03:23:05 +03:00
* 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.
Release 0.2 Yes, one day later. There were a couple of breaking changes that became clearly needed. I didn't expect this to get as much traffic as it has, so I'd like to get these changes made before too many people rely on the old behavior. See the CHANGELOG for specific API changes.
2015-11-30 20:29:37 +03:00
## [0.2.0] - 2015-11-30
Ensure that `Error` cannot be exhaustively matched on This is going to be the "generic thing which can fail in a myriad of ways" type. I want to be able to have specific useful cases which you can recover from (e.g. no `Box<std::error::Error>`), but I don't want people to exhaustively match on it. Techincally adding a variant to this is still a violation of [RFC #1105](https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md), but if you're actually matching against `__Nonexhaustive` and expected it not to break eventually, you knew what was coming. If some form of [RFC #757](https://github.com/rust-lang/rfcs/pull/757) ever lands, we'll switch to using that instead.
2015-11-30 00:59:46 +03:00
Replace `Connection#execute_returning_count` with `command.execute` Using `update` and `delete` was previously quite annoying to write. This makes the API feel much more fluid, and reads better if you're not actually using the count. Since `insert` is coming in this release as well, this will make things more useable.
2015-11-30 16:53:32 +03:00
### 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.
Add `get_result` and `get_results` to SQL commands These are intended to be used in favor of `query_one` and `query_all`, which are now hidden from the public API. I originally was going to name these `run` and `run_all`, but I didn't like the name `run_all`, nor the fact that `run` and `execute` are synonyms ("Do I call `memcpy` or `memmov` here?") Fixes #29
2015-11-30 19:22:04 +03:00
* 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.
Change `insert` to mirror `update` and `delete` This was a wart from the earliest days of implementation. It's inconsistent, and feels weird in place with the rest of the commands. I felt weird about the `Copy` bound on `InsertStatement`, but it ends up being required and makes sense when you consider that we'll always be passed references. However, it can potentially lead to some confusing error messages. The old methods on `Connection` are deprecated, and will be removed in the next release. Fixes #30.
2015-11-30 20:26:37 +03:00
* Added [`insert`][insert], which mirrors the pattern of `update` and `delete`.
Ensure that `Error` cannot be exhaustively matched on This is going to be the "generic thing which can fail in a myriad of ways" type. I want to be able to have specific useful cases which you can recover from (e.g. no `Box<std::error::Error>`), but I don't want people to exhaustively match on it. Techincally adding a variant to this is still a violation of [RFC #1105](https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md), but if you're actually matching against `__Nonexhaustive` and expected it not to break eventually, you knew what was coming. If some form of [RFC #757](https://github.com/rust-lang/rfcs/pull/757) ever lands, we'll switch to using that instead.
2015-11-30 00:59:46 +03:00
### 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.
For `query_one` and friends, not returning records is an error condition Through usage, it has become clear that in the overwhelming majority of cases, you either expect N records, or exactly 1. Expecting either 0 or 1 is uncommon. However, it's a completely valid use case, and having to match against `Err(NotFound)` is a pain, especially if you intend to use `try!`. Keeping that in mind, `QueryResult` now has the `optional` method, which converts `QueryResult<T>` to `QueryResult<Option<T>>`, treating `NotFound` as `None`. Since [`result::Error` is not exhaustively matchable](https://github.com/sgrif/diesel/commit/5435e30f1dc28008a8bef34c889998a0b009f0c4), I do not think we need to change the error type in this method. Since checking for and handling `NotFound` seems like a common case, particularly for returning a 404 response in a web server, it has been re-exported in the root namespace. I was going to open a PR to get feedback on this change first, but after making it, I feel the code quality improvement in our tests (especially the doctests, where we've removed most `.unwrap()` calls) was enough to convince me this is the right change.
2015-11-30 03:35:46 +03:00
* `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)`.
Change `insert` to mirror `update` and `delete` This was a wart from the earliest days of implementation. It's inconsistent, and feels weird in place with the rest of the commands. I felt weird about the `Copy` bound on `InsertStatement`, but it ends up being required and makes sense when you consider that we'll always be passed references. However, it can potentially lead to some confusing error messages. The old methods on `Connection` are deprecated, and will be removed in the next release. Fixes #30.
2015-11-30 20:26:37 +03:00
### Deprecated
* `Connection#insert` and `Connection#insert_returning_count` have been
deprecated in favor of [`insert`][insert]
Replace all links to the github pages site Github does *not* redirect github pages traffic when a repository is transferred to a new org. I can point the DNS to the new address, but any links that don't go somewhere on the diesel.rs domain will become dead soon.
2016-04-18 17:45:05 +03:00
[insert]: http://docs.diesel.rs/diesel/query_builder/fn.insert.html
Change `insert` to mirror `update` and `delete` This was a wart from the earliest days of implementation. It's inconsistent, and feels weird in place with the rest of the commands. I felt weird about the `Copy` bound on `InsertStatement`, but it ends up being required and makes sense when you consider that we'll always be passed references. However, it can potentially lead to some confusing error messages. The old methods on `Connection` are deprecated, and will be removed in the next release. Fixes #30.
2015-11-30 20:26:37 +03:00
Ensure that `Error` cannot be exhaustively matched on This is going to be the "generic thing which can fail in a myriad of ways" type. I want to be able to have specific useful cases which you can recover from (e.g. no `Box<std::error::Error>`), but I don't want people to exhaustively match on it. Techincally adding a variant to this is still a violation of [RFC #1105](https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md), but if you're actually matching against `__Nonexhaustive` and expected it not to break eventually, you knew what was coming. If some form of [RFC #757](https://github.com/rust-lang/rfcs/pull/757) ever lands, we'll switch to using that instead.
2015-11-30 00:59:46 +03:00
## [0.1.0] - 2015-11-29
* Initial release
Reference in New Issue Copy Permalink