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
d75f9483fb
diesel/CHANGELOG.md

113 lines
4.2 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)
Add debugging query builder and open up public api with macros
2015-12-06 21:20:51 +03:00
## Unreleased
### Added
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
the [migrations](http://sgrif.github.io/diesel/diesel/migrations/index.html)
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
[#63](https://github.com/sgrif/diesel/issues/63).
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
field on a changeset. Fixes [#68](https://github.com/sgrif/diesel/issues/68).
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
other than `id`. Fixes [#66](https://github.com/sgrif/diesel/issues/66).
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
[#65](https://github.com/sgrif/diesel/issues/65).
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
implements `Queriable` for the right SQL type
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
* `#[derive(Queriable)]` 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]
[insert]: http://sgrif.github.io/diesel/diesel/query_builder/fn.insert.html
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