From 905c73af78f7470b3e9cac20641c48c17b978d04 Mon Sep 17 00:00:00 2001
From: Christian Legnitto <christian@legnitto.com>
Date: Mon, 17 Dec 2018 14:02:33 -0800
Subject: [PATCH] Move juniper changelog to a single file in juniper crate
---
changelog/0.10.0.md | 58 -----
changelog/0.9.0.md | 95 -------
changelog/0.9.2.md | 13 -
changelog/master.md | 89 -------
changelog/older.md | 340 -------------------------
juniper/CHANGELOG.md | 582 +++++++++++++++++++++++++++++++++++++++++++
6 files changed, 582 insertions(+), 595 deletions(-)
delete mode 100644 changelog/0.10.0.md
delete mode 100644 changelog/0.9.0.md
delete mode 100644 changelog/0.9.2.md
delete mode 100644 changelog/master.md
delete mode 100644 changelog/older.md
create mode 100644 juniper/CHANGELOG.md
diff --git a/changelog/0.10.0.md b/changelog/0.10.0.md
deleted file mode 100644
index f56d9da2..00000000
--- a/changelog/0.10.0.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# [0.10.0] 2018-09-13
-
-## Changes
-
-- Changed serialization of `NaiveDate` when using the optional `chronos` support.
-
- **Note:** while this is not a Rust breaking change, if you relied on the serialization format (perhaps by storing serialized data in a database or making asumptions in your client code written in another language) it could be a breaking change for your application.
-
- [#151](https://github.com/graphql-rust/juniper/pull/151)
-
-- The `GraphQLObject`, `GraphQLInputObject`, and `GraphQLEnum` custom derives will reject
- invalid [names](http://facebook.github.io/graphql/October2016/#Name) at compile time.
-
- [#170](https://github.com/graphql-rust/juniper/pull/170)
-
-- Large integers (> signed 32bit) are now deserialized as floats. Previously,
- they produced an "integer out of range" error. For languages that do not
- have a distinction between integer and floating point types (such as
- javascript), this meant large whole floating point values could not be
- decoded (because they were represented without a fractional value such as `.0`).
-
- [#179](https://github.com/graphql-rust/juniper/pull/179)
-
-- The `GraphQLObject`, `GraphQLInputObject`, and `GraphQLEnum` custom derives
- now parse doc strings and use them as descriptions. This behavior can be
- overridden by using an explicit GraphQL `description` annotation such as
- `#[graphql(description = "my description")]`. [View documentation](https://graphql-rust.github.io/types/objects/defining_objects.html#defining-objects).
-
- [#194](https://github.com/graphql-rust/juniper/issues/194)
-
-- Introduced `IntoFieldError` trait to allow custom error handling
- i.e. custom result type. The error type must implement this trait resolving
- the errors into `FieldError`. [View documentation](https://graphql-rust.github.io/types/objects/error_handling.html#structured-errors).
-
- [#40](https://github.com/graphql-rust/juniper/issues/40)
-
-- `GraphQLType` and `ToInputValue` are now implemented for Arc<T>
-
- [#212](https://github.com/graphql-rust/juniper/pull/212)
-
-- Error responses no longer have a _data_ field, instead, error details are stored in the _extensions_ field
-
- **Note:** while this is a breaking change, it is a necessary one to better align with the latest [GraphQL June 2018](https://facebook.github.io/graphql/June2018/#sec-Errors) specification, which defines the reserved _extensions_ field for error details. [View documentation](https://graphql-rust.github.io/types/objects/error_handling.html#structured-errors).
-
- [#219](https://github.com/graphql-rust/juniper/pull/219)
-
-* The `GraphQLObject` and `GraphQLInputObject` custom derives
- now support lifetime annotations.
-
- [#225](https://github.com/graphql-rust/juniper/issues/225)
-
-* When using the `GraphQLObject` custom derive, fields can now be omitted by annotating the field with `#[graphql(skip)]`. [View documentation](https://graphql-rust.github.io/types/objects/defining_objects.html#skipping-fields).
-
- [#220](https://github.com/graphql-rust/juniper/issues/220)
-
-* Due to newer dependencies, the oldest Rust version supported is now 1.22.0
-
- [#231](https://github.com/graphql-rust/juniper/pull/231)
diff --git a/changelog/0.9.0.md b/changelog/0.9.0.md
deleted file mode 100644
index 1b67aa9b..00000000
--- a/changelog/0.9.0.md
+++ /dev/null
@@ -1,95 +0,0 @@
-
-## [0.9.0] 2017-12-03
-
-## Changes
-
-This is the first release in a long time.
-Quite a few changes have accumulated since `0.8.1`, including multiple breaking
-changes.
-
-### Custom derive & macros
-
-Juniper has gained custom derive implementations for input objects, objects and
-enums.
-
-* `#[derive(GraphQLInputObject)]`
-* `#[derive(GraphQLEnum)]`
-* `#[derive(GraphQLObject)]`
-
-The `graphql_enum!` and `graphql_input_object!` macros did not provide any more
-benefits, so they have been removed!
-All functionality is now covered by custom derive.
-Check the [docs](https://graphql-rust.github.io) to find out more.
-
-### Web framework integrations - Iron & Rocket
-
-The iron and rocket integrations were removed from the main crate, and are now
-available via the [juniper_iron](https://crates.io/crates/juniper_iron) and
-[juniper_rocket](https://crates.io/crates/juniper_rocket) crates.
-
-### FieldError rewrite (custom data)
-
-The `FieldError` type now supports custom data with the `Value` type from
-serde_json. Use this to populate the `data` field in returned errors.
-
-This also means that try! and `?` now work in resolvers, which is quite nice.
-
-Also, the `ResultExt` extension and the `jtry!` macro were removed, since they
-are redundant now!
-
-### Dynamic Schemas
-
-Juniper has gained support for dynamic schemas, thanks to @srijs.
-
-That also means the type of `RootNode` has changed to include a lifetime.
-
-The repository was restructured to a multi crate workspace to enable several new
-features like custom_derive and an extracted parser.
-
-#[#66](https://github.com/graphql-rust/juniper/pull/66)
-
-### Data Type Integrations
-
-Integrations with multiple popular crates was added to make working with them
-easier.
-
-* uuid
-* url
-* chrono
-
-### Field Order
-
-To better comply with the specification, order of requested fields is
-now preserved.
-
-[#82](https://github.com/graphql-rust/juniper/issues/82
-
-### From/ToInputValue
-
-The `::from` and `::to` methods in `From/ToInputValue` were renamed to
-`from/to_input_value()` to not conflict with other methods.
-
-[#90](https://github.com/graphql-rust/juniper/pull/90)
-
-### Other changes
-
-* Several small performance improvements
-* Use [fnv](https://github.com/servo/rust-fnv) hash map for better performance
-
-
-## Contributors
-
-A big shoutout to the many contributors for this version, sorted alphabetically.
-
-* Cameron Eldridge <cameldridge+git@gmail.com>
-* Christian Legnitto <christian@legnitto.com>
-* Jacob Haslehurst <jacob@haslehurst.net>
-* Jane Keibler <wanderingelf14@gmail.com>
-* Magnus Hallin <mhallin@fastmail.com>
-* rushmorem <rushmore@webenchanter.com>
-* Rushmore Mushambi <rushmore@webenchanter.com>
-* Sagie Gur-Ari <sagiegurari@gmail.com>
-* Sam Rijs <srijs@airpost.net>
-* Stanko Krtalić <stanko.krtalic@gmail.com>
-* theduke <chris@theduke.at>
-* thomas-jeepe <penguinSoccer@outlook.com>
diff --git a/changelog/0.9.2.md b/changelog/0.9.2.md
deleted file mode 100644
index b3a09336..00000000
--- a/changelog/0.9.2.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# [0.9.2] 2018-01-13
-
-## Changes
-
-### `__typename` for unions
-
-The [`__typename`](http://graphql.org/learn/queries/#meta-fields) query meta-field now works on unions.
-
-[#112](https://github.com/graphql-rust/juniper/issues/112)
-
-### Debug impls.
-
-http::GraphQLRequest now implements `Debug`.
diff --git a/changelog/master.md b/changelog/master.md
deleted file mode 100644
index 2eb32fb8..00000000
--- a/changelog/master.md
+++ /dev/null
@@ -1,89 +0,0 @@
-# [master] yyyy-mm-dd
-
-## Changes
-
-- The minimum required Rust version is now `1.28.0`.
-
- [#271](https://github.com/graphql-rust/juniper/pull/271)
-
-- Juniper is now generic about the exact representation of scalar values. This
- allows downstream crates to add support for own scalar value representations.
-
- There are two use cases for this feature:
- * You want to support new scalar types not representable by the provided default
- scalar value representation like for example `i64`
- * You want to support a type from a third party crate that is not supported by juniper
-
- **Note:** This may need some changes in down stream code, especially if working with
- generic code. To retain the current behaviour use `DefaultScalarValue` as scalar value type
-
- [#251](https://github.com/graphql-rust/juniper/pull/251)
-
-- The `GraphQLObject` and `GraphQLEnum` derives will mark graphql fields as
- `@deprecated` when struct fields or enum variants are marked with the
- builtin `#[deprecated]` attribute.
-
- The deprecation reason can be set using the `note = ...` meta item
- (e.g. `#[deprecated(note = "Replaced by betterField")]`).
- The `since` attribute is ignored.
-
- [#269](https://github.com/graphql-rust/juniper/pull/269)
-
-
-- There is an alternative syntax for setting a field's _description_ and
- _deprecation reason_ in the `graphql_object!` and `graphql_interface!` macros.
-
- To __deprecate__ a graphql field:
- ```rust
- // Original syntax for setting deprecation reason
- field deprecated "Reason" my_field() -> { ... }
-
- // New alternative syntax for deprecation reason.
- #[deprecated(note = "Reason")]
- field my_field() -> { ... }
-
- // You can now also deprecate without a reason.
- #[deprecated]
- field my_field() -> { ... }
- ```
-
- To set the __description__ of a graphql field:
- ```rust
- // Original syntax for field descriptions
- field my_field() as "Description" -> { ... }
-
- // Original syntax for argument descriptions
- field my_field(
- floops: i32 as "The number of starfish to be returned. \
- Can't be more than 100.",
- ) -> {
- ...
- }
-
- // New alternative syntax for field descriptions
- /// Description
- field my_field() -> { ... }
-
- // New alternative syntax for argument descriptions
- field my_field(
- /// The number of starfish to be returned.
- /// Can't be more than 100.
- arg: i32,
- ) -> {
- ...
- }
-
- // You can also use raw strings and const &'static str.
- //
- // Multiple docstrings will be collapsed into a single
- // description separated by newlines.
- /// This is my field.
- ///
- /// Make sure not to filtz the bitlet.
- /// Flitzing without a bitlet has undefined behaviour.
- ///
- #[doc = my_consts::ADDED_IN_VERSION_XYZ]
- field my_field() -> { ... }
- ```
-
- [#269](https://github.com/graphql-rust/juniper/pull/269)
diff --git a/changelog/older.md b/changelog/older.md
deleted file mode 100644
index 182f201b..00000000
--- a/changelog/older.md
+++ /dev/null
@@ -1,340 +0,0 @@
-Change log
-==========
-
-
-## [0.8.1] – 2017-06-15
-
-Tiny release to fix broken crate metadata on crates.io.
-
-## [0.8.0] – 2017-06-15
-
-## Breaking changes
-
-* To better comply with the specification, and to avoid weird bugs with very
- large positive or negative integers, support for `i64` has been completely
- dropped and replaced with `i32`. `i64` is no longer a valid GraphQL type in
- Juniper, and `InputValue`/`Value` can only represent 32 bit integers.
-
- If an incoming integer is out of range for a 32 bit signed integer type, an
- error will be returned to the client.
- ([#52](https://github.com/graphql-rust/juniper/issues/52),
- [#49](https://github.com/graphql-rust/juniper/issues/49))
-
-* Serde has been updated to 1.0. If your application depends on an older
- version, you will need to first update your application before you can upgrade
- to a more recent Juniper. ([#43](https://github.com/graphql-rust/juniper/pull/43))
-
-* `rustc_serialize` support has been dropped since this library is now
- deprecated. ([#51](https://github.com/graphql-rust/juniper/pull/51))
-
-## New features
-
-* A new `rocket-handlers` feature now includes some tools to use the
- [Rocket](https://rocket.rs) framework. [A simple
- example](juniper_rocket/examples/rocket-server.rs) has been added to the examples folder.
-
-## Bugfixes
-
-* A panic in the parser has been replaced with a proper error
- ([#44](https://github.com/graphql-rust/juniper/pull/44))
-
-## [0.7.0] – 2017-02-26
-
-### Breaking changes
-
-* The `iron-handlers` feature now depends on Iron 0.5
- ([#30](https://github.com/graphql-rust/juniper/pull/30)). Because of
- this, support for Rust 1.12 has been dropped. It might still work if
- you're not using the Iron integrations feature, however.
-
-### New features
-
-* Input objects defined by the `graphql_input_object!` can now be used
- as default values to field arguments and other input object fields.
-
-
-## [0.6.3] – 2017-02-19
-
-### New features
-
-* Add support for default values on input object fields
- ([#28](https://github.com/graphql-rust/juniper/issues/28))
-
-## [0.6.2] – 2017-02-05
-
-### New features
-
-* The `null` literal is now supported in the GraphQL
- language. ([#26](https://github.com/graphql-rust/juniper/pull/26))
-* Rustc-serialize is now optional, but enabled by default. If you
- _only_ want Serde support, include Juniper without default features
- and enable
- Serde. ([#12](https://github.com/graphql-rust/juniper/pull/12))
-* The built-in `ID` type now has a public constructor and derives a
- few traits (`Clone`, `Debug`, `Eq`, `PartialEq`, `From<String>`,
- `Deref<Target=str>`). ([#19](https://github.com/graphql-rust/juniper/pull/19))
-* Juniper is now built and tested against all Rust compilers since
- version 1.12.1.
-
-### Minor breaking change
-
-* Serde has been updated to
- 0.9. ([#25](https://github.com/graphql-rust/juniper/pull/25))
-
-### Bugfixes
-
-* The built-in GraphiQL handler had a bug in variable serialization.
- ([#16](https://github.com/graphql-rust/juniper/pull/16))
-* The example should now build and run without problems on
- Windows. ([#15](https://github.com/graphql-rust/juniper/pull/15))
-* Object types now properly implement
- `__typename`. ([#22](https://github.com/graphql-rust/juniper/pull/22))
-* String variables are now properly parsed into GraphQL
- enums. ([#17](https://github.com/graphql-rust/juniper/pull/17))
-
-## [0.6.1] – 2017-01-06
-
-### New features
-
-* Optional Serde support
- ([#8](https://github.com/graphql-rust/juniper/pull/8))
-
-### Improvements
-
-* The `graphql_input_object!` macro can now be used to define input
- objects as public Rust structs.
-* GraphiQL in the Iron GraphiQL handler has been updated to 0.8.1
- (#[#11](https://github.com/graphql-rust/juniper/pull/11))
-
-### Minor breaking changes
-
-Some undocumented but public APIs were changed.
-
-* `to_snake_case` correctly renamed to `to_camel_case`
- ([#9](https://github.com/graphql-rust/juniper/pull/9))
-* JSON serialization of `GraphQLError` changed to be more consistent
- with how other values were serialized
- ([#10](https://github.com/graphql-rust/juniper/pull/10)).
-
-## [0.6.0] – 2017-01-02
-
-TL;DR: Many big changes in how context types work and how they
-interact with the executor. Not too much to worry about if you're only
-using the macros and not deriving `GraphQLType` directly.
-
-### Breaking changes
-
-* The `executor` argument in all resolver methods is now
- immutable. The executor instead uses interior mutability to store
- errors in a thread-safe manner.
-
- This change could open up for asynchronous or multi-threaded
- execution: you can today use something like rayon in your resolve
- methods to let child nodes be concurrently resolved.
-
- **How to fix:** All field resolvers that looked like `field
- name(&mut executor` now should say `field name(&executor`.
-
-* The context type of `GraphQLType` is moved to an associated type;
- meaning it's no longer generic. This only affects people who
- implement the trait manually, _not_ macro users.
-
- This greatly simplifies a lot of code by ensuring that there only
- can be one `GraphQLType` implementation for any given Rust
- type. However, it has the downside that support for generic contexts
- previously used in scalars, has been removed. Instead, use the new
- context conversion features to accomplish the same task.
-
- **How to fix:** Instead of `impl GraphQLType<MyContext> for ...`,
- you use `impl GraphQLType for ... { type Context = MyContext;`.
-
-* All context types must derive the `Context` marker trait. This is
- part of an overarching change to allow different types to use
- different contexts.
-
- **How to fix:** If you have written e.g. `graphql_object!(MyType:
- MyContext ...)` you will need to add `impl Context for MyContext
- {}`. Simple as that.
-
-* `Registry` and all meta type structs now takes one lifetime
- parameter, which affects `GraphQLType`'s `meta` method. This only
- affects people who implement the trait manually.
-
- **How to fix:** Change the type signature of `meta()` to read `fn
- meta<'r>(registry: &mut Registry<'r>) -> MetaType<'r>`.
-
-* The type builder methods on `Registry` no longer return functions
- taking types or fields. Due to how the borrow checker works with
- expressions, you will have to split up the instantiation into two
- statements. This only affects people who implement the `GraphQLType`
- trait manually.
-
- **How to fix:** Change the contents of your `meta()` methods to
- something like this:
-
- ```rust
- fn meta<'r>(registry: &mut Registry<r>) -> MetaType<'r> {
- let fields = &[ /* your fields ... */ ];
-
- registry.build_object_type::<Self>(fields).into_meta()
- }
-
- ```
-
-
-### Added
-
-* Support for different contexts for different types. As GraphQL
- schemas tend to get large, narrowing down the context type to
- exactly what a given type needs is great for
- encapsulation. Similarly, letting different subsystems use different
- resources thorugh the context is also useful for the same reasons.
-
- Juniper supports two different methods of doing this, depending on
- your needs: if you have two contexts where one can be converted into
- the other _without any extra knowledge_, you can implement the new
- `FromContext` trait. This is useful if you have multiple crates or
- modules that all belong to the same GraphQL schema:
-
- ```rust
-
- struct TopContext {
- db: DatabaseConnection,
- session: WebSession,
- current_user: User,
- }
-
- struct ModuleOneContext {
- db: DatabaseConnection, // This module only requires a database connection
- }
-
- impl Context for TopContext {}
- impl Context for ModuleOneContext {}
-
- impl FromContext<TopContext> for ModuleOneContext {
- fn from(ctx: &TopContext) -> ModuleOneContext {
- ModuleOneContext {
- db: ctx.db.clone()
- }
- }
- }
-
- graphql_object!(Query: TopContext |&self| {
- field item(&executor) -> Item {
- executor.context().db.get_item()
- }
- });
-
- // The `Item` type uses another context type - conversion is automatic
- graphql_object!(Item: ModuleOneContext |&self| {
- // ...
- });
-
- ```
-
- The other way is to manually perform the conversion in a field
- resolver. This method is preferred when the child context needs
- extra knowledge than what exists in the parent context:
-
- ```rust
-
- // Each entity has its own context
- struct TopContext {
- entities: HashMap<i32, EntityContext>,
- db: DatabaseConnection,
- }
-
- struct EntityContext {
- // fields
- }
-
- impl Context for TopContext {}
- impl Context for EntityContext {}
-
- graphql_object!(Query: TopContext |&self| {
- // By returning a tuple (&Context, GraphQLType), you can tell the executor
- // to switch out the context for the returned value. You can wrap the
- // tuple in Option<>, FieldResult<>, FieldResult<Option<>>, or just return
- // the tuple without wrapping it.
- field entity(&executor, key: i32) -> Option<(&EntityContext, Entity)> {
- executor.context().entities.get(&key)
- .map(|ctx| (ctx, executor.context().db.get_entity(key)))
- }
- });
-
- graphql_object!(Entity: EntityContext |&self| {
- // ...
- });
-
- ```
-
-### Improvements
-
-* Parser and query execution has now reduced the allocation overhead
- by reusing as much as possible from the query source and meta type
- information.
-
-## [0.5.3] – 2016-12-05
-
-### Added
-
-* `jtry!`: Helper macro to produce `FieldResult`s from regular
- `Result`s. Wherever you would be using `try!` in a regular function
- or method, you can use `jtry!` in a field resolver:
-
- ```rust
- graphql_object(MyType: Database |&self| {
- field count(&executor) -> FieldResult<i32> {
- let txn = jtry!(executor.context().transaction());
-
- let count = jtry!(txn.execute("SELECT COUNT(*) FROM user"));
-
- Ok(count[0][0])
- }
- });
- ```
-
-### Changes
-
-* Relax context type trait requirements for the iron handler: your
- contexts no longer have to be `Send + Sync`.
-
-* `RootNode` is now `Send` and `Sync` if both the mutation and query
- types implement `Send` and `Sync`.
-
-### Bugfixes
-
-* `return` statements inside field resolvers no longer cause syntax
- errors.
-
-
-
-## 0.5.2 – 2016-11-13
-
-### Added
-
-* Support for marking fields and enum values deprecated.
-* `input_object!` helper macro
-
-### Changes
-
-* The included example server now uses the simple Star Wars schema
- used in query/introspection tests.
-
-### Bugfixes
-
-* The query validators - particularly ones concerned with validation
- of input data and variables - have been improved significantly. A
- large number of test cases have been added.
-
-* Macro syntax stability has also been improved. All syntactical edge
- cases of the macros have gotten tests to verify their correctness.
-
-[0.8.0]: https://github.com/graphql-rust/juniper/compare/0.8.0...0.8.1
-[0.8.0]: https://github.com/graphql-rust/juniper/compare/0.7.0...0.8.0
-[0.7.0]: https://github.com/graphql-rust/juniper/compare/0.6.3...0.7.0
-[0.6.3]: https://github.com/graphql-rust/juniper/compare/0.6.2...0.6.3
-[0.6.2]: https://github.com/graphql-rust/juniper/compare/0.6.1...0.6.2
-[0.6.1]: https://github.com/graphql-rust/juniper/compare/0.6.0...0.6.1
-[0.6.0]: https://github.com/graphql-rust/juniper/compare/0.5.3...0.6.0
-[0.5.3]: https://github.com/graphql-rust/juniper/compare/0.5.2...0.5.3
diff --git a/juniper/CHANGELOG.md b/juniper/CHANGELOG.md
new file mode 100644
index 00000000..f8df9e74
--- /dev/null
+++ b/juniper/CHANGELOG.md
@@ -0,0 +1,582 @@
+# master
+
+## Changes
+
+- The minimum required Rust version is now `1.28.0`.
+
+ [#271](https://github.com/graphql-rust/juniper/pull/271)
+
+- Juniper is now generic about the exact representation of scalar values. This
+ allows downstream crates to add support for own scalar value representations.
+
+ There are two use cases for this feature:
+
+ - You want to support new scalar types not representable by the provided default
+ scalar value representation like for example `i64`
+ - You want to support a type from a third party crate that is not supported by juniper
+
+ **Note:** This may need some changes in down stream code, especially if working with
+ generic code. To retain the current behaviour use `DefaultScalarValue` as scalar value type
+
+ [#251](https://github.com/graphql-rust/juniper/pull/251)
+
+- The `GraphQLObject` and `GraphQLEnum` derives will mark graphql fields as
+ `@deprecated` when struct fields or enum variants are marked with the
+ builtin `#[deprecated]` attribute.
+
+ The deprecation reason can be set using the `note = ...` meta item
+ (e.g. `#[deprecated(note = "Replaced by betterField")]`).
+ The `since` attribute is ignored.
+
+ [#269](https://github.com/graphql-rust/juniper/pull/269)
+
+* There is an alternative syntax for setting a field's _description_ and
+ _deprecation reason_ in the `graphql_object!` and `graphql_interface!` macros.
+
+ To **deprecate** a graphql field:
+
+ ```rust
+ // Original syntax for setting deprecation reason
+ field deprecated "Reason" my_field() -> { ... }
+
+ // New alternative syntax for deprecation reason.
+ #[deprecated(note = "Reason")]
+ field my_field() -> { ... }
+
+ // You can now also deprecate without a reason.
+ #[deprecated]
+ field my_field() -> { ... }
+ ```
+
+ To set the **description** of a graphql field:
+
+ ```rust
+ // Original syntax for field descriptions
+ field my_field() as "Description" -> { ... }
+
+ // Original syntax for argument descriptions
+ field my_field(
+ floops: i32 as "The number of starfish to be returned. \
+ Can't be more than 100.",
+ ) -> {
+ ...
+ }
+
+ // New alternative syntax for field descriptions
+ /// Description
+ field my_field() -> { ... }
+
+ // New alternative syntax for argument descriptions
+ field my_field(
+ /// The number of starfish to be returned.
+ /// Can't be more than 100.
+ arg: i32,
+ ) -> {
+ ...
+ }
+
+ // You can also use raw strings and const &'static str.
+ //
+ // Multiple docstrings will be collapsed into a single
+ // description separated by newlines.
+ /// This is my field.
+ ///
+ /// Make sure not to filtz the bitlet.
+ /// Flitzing without a bitlet has undefined behaviour.
+ ///
+ #[doc = my_consts::ADDED_IN_VERSION_XYZ]
+ field my_field() -> { ... }
+ ```
+
+ [#269](https://github.com/graphql-rust/juniper/pull/269)
+
+# [0.10.0] 2018-09-13
+
+## Changes
+
+- Changed serialization of `NaiveDate` when using the optional `chronos` support.
+
+ **Note:** while this is not a Rust breaking change, if you relied on the serialization format (perhaps by storing serialized data in a database or making asumptions in your client code written in another language) it could be a breaking change for your application.
+
+ [#151](https://github.com/graphql-rust/juniper/pull/151)
+
+- The `GraphQLObject`, `GraphQLInputObject`, and `GraphQLEnum` custom derives will reject
+ invalid [names](http://facebook.github.io/graphql/October2016/#Name) at compile time.
+
+ [#170](https://github.com/graphql-rust/juniper/pull/170)
+
+- Large integers (> signed 32bit) are now deserialized as floats. Previously,
+ they produced an "integer out of range" error. For languages that do not
+ have a distinction between integer and floating point types (such as
+ javascript), this meant large whole floating point values could not be
+ decoded (because they were represented without a fractional value such as `.0`).
+
+ [#179](https://github.com/graphql-rust/juniper/pull/179)
+
+- The `GraphQLObject`, `GraphQLInputObject`, and `GraphQLEnum` custom derives
+ now parse doc strings and use them as descriptions. This behavior can be
+ overridden by using an explicit GraphQL `description` annotation such as
+ `#[graphql(description = "my description")]`. [View documentation](https://graphql-rust.github.io/types/objects/defining_objects.html#defining-objects).
+
+ [#194](https://github.com/graphql-rust/juniper/issues/194)
+
+- Introduced `IntoFieldError` trait to allow custom error handling
+ i.e. custom result type. The error type must implement this trait resolving
+ the errors into `FieldError`. [View documentation](https://graphql-rust.github.io/types/objects/error_handling.html#structured-errors).
+
+ [#40](https://github.com/graphql-rust/juniper/issues/40)
+
+- `GraphQLType` and `ToInputValue` are now implemented for Arc<T>
+
+ [#212](https://github.com/graphql-rust/juniper/pull/212)
+
+- Error responses no longer have a _data_ field, instead, error details are stored in the _extensions_ field
+
+ **Note:** while this is a breaking change, it is a necessary one to better align with the latest [GraphQL June 2018](https://facebook.github.io/graphql/June2018/#sec-Errors) specification, which defines the reserved _extensions_ field for error details. [View documentation](https://graphql-rust.github.io/types/objects/error_handling.html#structured-errors).
+
+ [#219](https://github.com/graphql-rust/juniper/pull/219)
+
+* The `GraphQLObject` and `GraphQLInputObject` custom derives
+ now support lifetime annotations.
+
+ [#225](https://github.com/graphql-rust/juniper/issues/225)
+
+* When using the `GraphQLObject` custom derive, fields can now be omitted by annotating the field with `#[graphql(skip)]`. [View documentation](https://graphql-rust.github.io/types/objects/defining_objects.html#skipping-fields).
+
+ [#220](https://github.com/graphql-rust/juniper/issues/220)
+
+* Due to newer dependencies, the oldest Rust version supported is now 1.22.0
+
+ [#231](https://github.com/graphql-rust/juniper/pull/231)
+
+# [0.9.2] 2018-01-13
+
+## Changes
+
+### `__typename` for unions
+
+The [`__typename`](http://graphql.org/learn/queries/#meta-fields) query meta-field now works on unions.
+
+[#112](https://github.com/graphql-rust/juniper/issues/112)
+
+### Debug impls.
+
+http::GraphQLRequest now implements `Debug`.
+
+# [0.9.0] 2017-12-03
+
+## Changes
+
+This is the first release in a long time.
+Quite a few changes have accumulated since `0.8.1`, including multiple breaking
+changes.
+
+### Custom derive & macros
+
+Juniper has gained custom derive implementations for input objects, objects and
+enums.
+
+- `#[derive(GraphQLInputObject)]`
+- `#[derive(GraphQLEnum)]`
+- `#[derive(GraphQLObject)]`
+
+The `graphql_enum!` and `graphql_input_object!` macros did not provide any more
+benefits, so they have been removed!
+All functionality is now covered by custom derive.
+Check the [docs](https://graphql-rust.github.io) to find out more.
+
+### Web framework integrations - Iron & Rocket
+
+The iron and rocket integrations were removed from the main crate, and are now
+available via the [juniper_iron](https://crates.io/crates/juniper_iron) and
+[juniper_rocket](https://crates.io/crates/juniper_rocket) crates.
+
+### FieldError rewrite (custom data)
+
+The `FieldError` type now supports custom data with the `Value` type from
+serde_json. Use this to populate the `data` field in returned errors.
+
+This also means that try! and `?` now work in resolvers, which is quite nice.
+
+Also, the `ResultExt` extension and the `jtry!` macro were removed, since they
+are redundant now!
+
+### Dynamic Schemas
+
+Juniper has gained support for dynamic schemas, thanks to @srijs.
+
+That also means the type of `RootNode` has changed to include a lifetime.
+
+The repository was restructured to a multi crate workspace to enable several new
+features like custom_derive and an extracted parser.
+
+#[#66](https://github.com/graphql-rust/juniper/pull/66)
+
+### Data Type Integrations
+
+Integrations with multiple popular crates was added to make working with them
+easier.
+
+- uuid
+- url
+- chrono
+
+### Field Order
+
+To better comply with the specification, order of requested fields is
+now preserved.
+
+[#82](https://github.com/graphql-rust/juniper/issues/82
+
+### From/ToInputValue
+
+The `::from` and `::to` methods in `From/ToInputValue` were renamed to
+`from/to_input_value()` to not conflict with other methods.
+
+[#90](https://github.com/graphql-rust/juniper/pull/90)
+
+### Other changes
+
+- Several small performance improvements
+- Use [fnv](https://github.com/servo/rust-fnv) hash map for better performance
+
+## Contributors
+
+A big shoutout to the many contributors for this version, sorted alphabetically.
+
+- Cameron Eldridge <mailto:cameldridge+git@gmail.com>
+- Christian Legnitto <mailto:christian@legnitto.com>
+- Jacob Haslehurst <mailto:jacob@haslehurst.net>
+- Jane Keibler <mailto:wanderingelf14@gmail.com>
+- Magnus Hallin <mailto:mhallin@fastmail.com>
+- rushmorem <mailto:rushmore@webenchanter.com>
+- Rushmore Mushambi <mailto:rushmore@webenchanter.com>
+- Sagie Gur-Ari <mailto:sagiegurari@gmail.com>
+- Sam Rijs <mailto:srijs@airpost.net>
+- Stanko Krtalić <mailto:stanko.krtalic@gmail.com>
+- theduke <mailto:chris@theduke.at>
+- thomas-jeepe <mailto:penguinSoccer@outlook.com>
+
+# [0.8.1] – 2017-06-15
+
+Tiny release to fix broken crate metadata on crates.io.
+
+# [0.8.0] – 2017-06-15
+
+## Breaking changes
+
+- To better comply with the specification, and to avoid weird bugs with very
+ large positive or negative integers, support for `i64` has been completely
+ dropped and replaced with `i32`. `i64` is no longer a valid GraphQL type in
+ Juniper, and `InputValue`/`Value` can only represent 32 bit integers.
+
+ If an incoming integer is out of range for a 32 bit signed integer type, an
+ error will be returned to the client.
+ ([#52](https://github.com/graphql-rust/juniper/issues/52),
+ [#49](https://github.com/graphql-rust/juniper/issues/49))
+
+- Serde has been updated to 1.0. If your application depends on an older
+ version, you will need to first update your application before you can upgrade
+ to a more recent Juniper. ([#43](https://github.com/graphql-rust/juniper/pull/43))
+
+- `rustc_serialize` support has been dropped since this library is now
+ deprecated. ([#51](https://github.com/graphql-rust/juniper/pull/51))
+
+## New features
+
+- A new `rocket-handlers` feature now includes some tools to use the
+ [Rocket](https://rocket.rs) framework. [A simple
+ example](juniper_rocket/examples/rocket-server.rs) has been added to the examples folder.
+
+## Bugfixes
+
+- A panic in the parser has been replaced with a proper error
+ ([#44](https://github.com/graphql-rust/juniper/pull/44))
+
+# [0.7.0] – 2017-02-26
+
+### Breaking changes
+
+- The `iron-handlers` feature now depends on Iron 0.5
+ ([#30](https://github.com/graphql-rust/juniper/pull/30)). Because of
+ this, support for Rust 1.12 has been dropped. It might still work if
+ you're not using the Iron integrations feature, however.
+
+### New features
+
+- Input objects defined by the `graphql_input_object!` can now be used
+ as default values to field arguments and other input object fields.
+
+# [0.6.3] – 2017-02-19
+
+### New features
+
+- Add support for default values on input object fields
+ ([#28](https://github.com/graphql-rust/juniper/issues/28))
+
+# [0.6.2] – 2017-02-05
+
+### New features
+
+- The `null` literal is now supported in the GraphQL
+ language. ([#26](https://github.com/graphql-rust/juniper/pull/26))
+- Rustc-serialize is now optional, but enabled by default. If you
+ _only_ want Serde support, include Juniper without default features
+ and enable
+ Serde. ([#12](https://github.com/graphql-rust/juniper/pull/12))
+- The built-in `ID` type now has a public constructor and derives a
+ few traits (`Clone`, `Debug`, `Eq`, `PartialEq`, `From<String>`,
+ `Deref<Target=str>`). ([#19](https://github.com/graphql-rust/juniper/pull/19))
+- Juniper is now built and tested against all Rust compilers since
+ version 1.12.1.
+
+### Minor breaking change
+
+- Serde has been updated to
+ 0.9. ([#25](https://github.com/graphql-rust/juniper/pull/25))
+
+### Bugfixes
+
+- The built-in GraphiQL handler had a bug in variable serialization.
+ ([#16](https://github.com/graphql-rust/juniper/pull/16))
+- The example should now build and run without problems on
+ Windows. ([#15](https://github.com/graphql-rust/juniper/pull/15))
+- Object types now properly implement
+ `__typename`. ([#22](https://github.com/graphql-rust/juniper/pull/22))
+- String variables are now properly parsed into GraphQL
+ enums. ([#17](https://github.com/graphql-rust/juniper/pull/17))
+
+# [0.6.1] – 2017-01-06
+
+### New features
+
+- Optional Serde support
+ ([#8](https://github.com/graphql-rust/juniper/pull/8))
+
+### Improvements
+
+- The `graphql_input_object!` macro can now be used to define input
+ objects as public Rust structs.
+- GraphiQL in the Iron GraphiQL handler has been updated to 0.8.1
+ (#[#11](https://github.com/graphql-rust/juniper/pull/11))
+
+### Minor breaking changes
+
+Some undocumented but public APIs were changed.
+
+- `to_snake_case` correctly renamed to `to_camel_case`
+ ([#9](https://github.com/graphql-rust/juniper/pull/9))
+- JSON serialization of `GraphQLError` changed to be more consistent
+ with how other values were serialized
+ ([#10](https://github.com/graphql-rust/juniper/pull/10)).
+
+# [0.6.0] – 2017-01-02
+
+TL;DR: Many big changes in how context types work and how they
+interact with the executor. Not too much to worry about if you're only
+using the macros and not deriving `GraphQLType` directly.
+
+### Breaking changes
+
+- The `executor` argument in all resolver methods is now
+ immutable. The executor instead uses interior mutability to store
+ errors in a thread-safe manner.
+
+ This change could open up for asynchronous or multi-threaded
+ execution: you can today use something like rayon in your resolve
+ methods to let child nodes be concurrently resolved.
+
+ **How to fix:** All field resolvers that looked like `field name(&mut executor` now should say `field name(&executor`.
+
+- The context type of `GraphQLType` is moved to an associated type;
+ meaning it's no longer generic. This only affects people who
+ implement the trait manually, _not_ macro users.
+
+ This greatly simplifies a lot of code by ensuring that there only
+ can be one `GraphQLType` implementation for any given Rust
+ type. However, it has the downside that support for generic contexts
+ previously used in scalars, has been removed. Instead, use the new
+ context conversion features to accomplish the same task.
+
+ **How to fix:** Instead of `impl GraphQLType<MyContext> for ...`,
+ you use `impl GraphQLType for ... { type Context = MyContext;`.
+
+- All context types must derive the `Context` marker trait. This is
+ part of an overarching change to allow different types to use
+ different contexts.
+
+ **How to fix:** If you have written e.g. `graphql_object!(MyType: MyContext ...)` you will need to add `impl Context for MyContext {}`. Simple as that.
+
+- `Registry` and all meta type structs now takes one lifetime
+ parameter, which affects `GraphQLType`'s `meta` method. This only
+ affects people who implement the trait manually.
+
+ **How to fix:** Change the type signature of `meta()` to read `fn meta<'r>(registry: &mut Registry<'r>) -> MetaType<'r>`.
+
+- The type builder methods on `Registry` no longer return functions
+ taking types or fields. Due to how the borrow checker works with
+ expressions, you will have to split up the instantiation into two
+ statements. This only affects people who implement the `GraphQLType`
+ trait manually.
+
+ **How to fix:** Change the contents of your `meta()` methods to
+ something like this:
+
+ ```rust
+ fn meta<'r>(registry: &mut Registry<r>) -> MetaType<'r> {
+ let fields = &[ /* your fields ... */ ];
+
+ registry.build_object_type::<Self>(fields).into_meta()
+ }
+ ```
+
+### Added
+
+- Support for different contexts for different types. As GraphQL
+ schemas tend to get large, narrowing down the context type to
+ exactly what a given type needs is great for
+ encapsulation. Similarly, letting different subsystems use different
+ resources thorugh the context is also useful for the same reasons.
+
+ Juniper supports two different methods of doing this, depending on
+ your needs: if you have two contexts where one can be converted into
+ the other _without any extra knowledge_, you can implement the new
+ `FromContext` trait. This is useful if you have multiple crates or
+ modules that all belong to the same GraphQL schema:
+
+ ```rust
+ struct TopContext {
+ db: DatabaseConnection,
+ session: WebSession,
+ current_user: User,
+ }
+
+ struct ModuleOneContext {
+ db: DatabaseConnection, // This module only requires a database connection
+ }
+
+ impl Context for TopContext {}
+ impl Context for ModuleOneContext {}
+
+ impl FromContext<TopContext> for ModuleOneContext {
+ fn from(ctx: &TopContext) -> ModuleOneContext {
+ ModuleOneContext {
+ db: ctx.db.clone()
+ }
+ }
+ }
+
+ graphql_object!(Query: TopContext |&self| {
+ field item(&executor) -> Item {
+ executor.context().db.get_item()
+ }
+ });
+
+ // The `Item` type uses another context type - conversion is automatic
+ graphql_object!(Item: ModuleOneContext |&self| {
+ // ...
+ });
+ ```
+
+ The other way is to manually perform the conversion in a field
+ resolver. This method is preferred when the child context needs
+ extra knowledge than what exists in the parent context:
+
+ ```rust
+ // Each entity has its own context
+ struct TopContext {
+ entities: HashMap<i32, EntityContext>,
+ db: DatabaseConnection,
+ }
+
+ struct EntityContext {
+ // fields
+ }
+
+ impl Context for TopContext {}
+ impl Context for EntityContext {}
+
+ graphql_object!(Query: TopContext |&self| {
+ // By returning a tuple (&Context, GraphQLType), you can tell the executor
+ // to switch out the context for the returned value. You can wrap the
+ // tuple in Option<>, FieldResult<>, FieldResult<Option<>>, or just return
+ // the tuple without wrapping it.
+ field entity(&executor, key: i32) -> Option<(&EntityContext, Entity)> {
+ executor.context().entities.get(&key)
+ .map(|ctx| (ctx, executor.context().db.get_entity(key)))
+ }
+ });
+
+ graphql_object!(Entity: EntityContext |&self| {
+ // ...
+ });
+ ```
+
+### Improvements
+
+- Parser and query execution has now reduced the allocation overhead
+ by reusing as much as possible from the query source and meta type
+ information.
+
+# [0.5.3] – 2016-12-05
+
+### Added
+
+- `jtry!`: Helper macro to produce `FieldResult`s from regular
+ `Result`s. Wherever you would be using `try!` in a regular function
+ or method, you can use `jtry!` in a field resolver:
+
+ ```rust
+ graphql_object(MyType: Database |&self| {
+ field count(&executor) -> FieldResult<i32> {
+ let txn = jtry!(executor.context().transaction());
+
+ let count = jtry!(txn.execute("SELECT COUNT(*) FROM user"));
+
+ Ok(count[0][0])
+ }
+ });
+ ```
+
+### Changes
+
+- Relax context type trait requirements for the iron handler: your
+ contexts no longer have to be `Send + Sync`.
+
+- `RootNode` is now `Send` and `Sync` if both the mutation and query
+ types implement `Send` and `Sync`.
+
+### Bugfixes
+
+- `return` statements inside field resolvers no longer cause syntax
+ errors.
+
+## 0.5.2 – 2016-11-13
+
+### Added
+
+- Support for marking fields and enum values deprecated.
+- `input_object!` helper macro
+
+### Changes
+
+- The included example server now uses the simple Star Wars schema
+ used in query/introspection tests.
+
+### Bugfixes
+
+- The query validators - particularly ones concerned with validation
+ of input data and variables - have been improved significantly. A
+ large number of test cases have been added.
+
+- Macro syntax stability has also been improved. All syntactical edge
+ cases of the macros have gotten tests to verify their correctness.
+
+[0.8.0]: https://github.com/graphql-rust/juniper/compare/0.8.0...0.8.1
+[0.8.0]: https://github.com/graphql-rust/juniper/compare/0.7.0...0.8.0
+[0.7.0]: https://github.com/graphql-rust/juniper/compare/0.6.3...0.7.0
+[0.6.3]: https://github.com/graphql-rust/juniper/compare/0.6.2...0.6.3
+[0.6.2]: https://github.com/graphql-rust/juniper/compare/0.6.1...0.6.2
+[0.6.1]: https://github.com/graphql-rust/juniper/compare/0.6.0...0.6.1
+[0.6.0]: https://github.com/graphql-rust/juniper/compare/0.5.3...0.6.0
+[0.5.3]: https://github.com/graphql-rust/juniper/compare/0.5.2...0.5.3