absinthe-graphql
diff --git a/‎.gitignore‎
Lines changed: 1 addition & 0 deletions b/‎.gitignore‎
Lines changed: 1 addition & 0 deletions
diff --git a/‎.travis.yml‎
Lines changed: 2 additions & 1 deletion b/‎.travis.yml‎
Lines changed: 2 additions & 1 deletion
diff --git a/‎CHANGELOG.md‎
Lines changed: 138 additions & 14 deletions b/‎CHANGELOG.md‎
Lines changed: 138 additions & 14 deletions
diff --git a/‎README.md‎
Lines changed: 53 additions & 28 deletions b/‎README.md‎
Lines changed: 53 additions & 28 deletions
@@ -6,3 +6,4 @@
 erl_crash.dump
 *.ez
 src/*.erl
+.tool-versions*
@@ -1,9 +1,10 @@
 language: elixir
-elixir: 1.2.0
+elixir: 1.3.0
 notifications:
   recipients:
     - bruce.williams@cargosense.com
     - ben.wilson@cargosense.com
 otp_release:
   - 18.0
+  - 19.0
 script: "MIX_ENV=test mix local.hex --force && MIX_ENV=test mix do deps.get, test"
@@ -1,39 +1,163 @@
 # Changelog
 
+## v1.2
+
+## Overview
+
+Absinthe now generates a richer "intermediate representation" of query
+documents (see `Absinthe.Blueprint`) from the document AST. This representation
+then serves as the data backbone for processing during later phases.
+
+Rather than the integrated validation-during-execution approach used in
+previous versions-- and rather than using a few "fat" phases (eg, "Parsing",
+"Validation", "Execution") as in other implementations -- Absinthe treats
+all operations (parsing, each individual validation, field resolution, and
+result construction) as a pipeline (see `Absinthe.Pipeline`) of discrete
+and equal phases. This allows developers to insert, remove, switch-out, and
+otherwise customize the changes that occur to the intermediate representation,
+and how that intermediate representation turns into a result. Future releases
+will further this model and continue to make it easier to modify Absinthe's
+processing to support the unique needs of developers.
+
+### Breaking Changes
+
+#### Deprecations and Errors
+
+Absinthe no longer automatically adds deprecations to result
+errors. (Although this is possible with the addition of custom
+phases.)
+
+#### More Strict Input Value Parsing
+
+Absinthe now more closely adheres to the GraphQL specification's rules
+about input value coercion, to include:
+
+- Int: Disallowing automatic coercion of, eg, `"1"` to `1`
+- String: Disallowing automatic coercion of, eg, `1` to `"1"`
+- Enum: Disallowing quoted values, eg, `"RED"` vs `RED`
+
+Furthermore scalar type `parse` functions now receive their value as
+`Absinthe.Blueprint.Input.t` structs. If you have defined your own
+custom scalar types, you may need to modify them; see
+`lib/absinthe/type/built_ins/scalars.ex` for examples.
+
+#### Validation Errors Prevent Resolution
+
+In accordance with the GraphQL Specification, if any errors are added
+during document validation, no resolution will occur. In the past,
+because validation was done on-the-fly during resolution, partial
+resolution, just returning `null` for fields (in a way that would be
+invalid, according to the spec) was possible.
+
+(Notably, this release includes a very large number of new document
+validations.)
+
+#### No AST Nodes in Resolution
+
+The raw AST nodes are no longer provided as part of the "info" argument passed
+to resolve functions. If you have built logic (eg, Ecto preloading) based on
+the AST information, look at the `definition` instead, which is a Blueprint
+`Field` struct containing a `fields` array of subfields. These fields have
+passed validation and have been flattened from any fragments that may have
+been used in the original document (you just may want to pay attention to
+each field's `type_conditions`).
+
+#### List Coercion
+
+Fields and arguments with list types are now automatically coerced if given a
+single item. For example if you have `arg :ids, list_of(:id)` Absinthe will coerce
+a document like `foo(ids: 1)` into `foo(ids: [1])`.
+
+This is also true for resolution functions. If your field has a return type of
+`list_of(:user)` and your resolution function returns `{:ok, %User{}}`, the value
+is wrapped. It is as though you returned `{:ok, [%User{}]}`.
+
+#### Simpler Adapters
+
+Adapters now only use `to_internal_name/2` and `to_external_name/2` as the
+`Absinthe.Blueprint` intermediate representation and schema application
+phase removes the need for whole document conversion. If you have defined
+your own adapter, you may need to modify it.
+
+#### Mix Task Removal
+
+The IDL generating mix task (`absinthe.schema.graphql`) has been temporarily
+removed (due to the extent of work needed to modify it for this release), but
+it will reappear in a future release along with integrated schema compilation
+from GraphQL IDL.
+
+### Other Changes
+
+#### Resolution Functions
+
+Support for 3-arity resolution functions. Resolution functions accepting 3
+arguments will have the current "source" (or parent) object passed as the
+first argument. 2-arity resolution functions will continue to be supported.
+
+The following resolutions functions are equivalent:
+
+```elixir
+fn source, args, info -> {:ok, source.foo} end
+fn args, %{source: source} -> {:ok, source.foo} end
+```
+
+#### Resolution Plugins (+ Async & Batching)
+
+v1.2 features a Resolution Plugin mechanism. See the docs in the
+`Absinthe.Resolution.Plugin` module for more information.
+
+#### Resolution Info
+
+In previous versions, the last argument to resolution functions was an
+`Absinthe.Execution.Field` struct. It is now an `Absinthe.Resolution` struct.
+While the struct has most of the same information available, the AST nodes
+is no longer provided. See "Breaking Changes" above.
+
+#### Custom Type Metadata
+
+To further support extensibility, types and fields can be annotated using the
+`Absinthe.Schema.Notation.meta/2` macro, and metadata extracted using
+`Absinthe.Type.meta/1` and `Absinthe.Type.meta/1`. This metadata facility has
+been added for objects, input objects, enums, scalars, unions, interfaces, and
+fields.
+
 ## v1.1.7
 
-Bugfixes
+### Bugfixes
+
 - Fix execution of nested fragment spreads with abstract condition types.
 
 ## v1.1.6
 
-Bugfixes
+### Bugfixes
+
 - Support adapting InterfaceDefinition structs; caused a warning when
   running the `absinthe.schema.graphql` mix task.
 - Fix missing newline after scalar type definitions in IDL output by
   the `absinthe.schema.graphql` mix task.
 
 ## v1.1.5
 
-Bugfixes
+### Bugfixes
+
 - Correctly stringify serialized default values when introspecting
 
 ## v1.1.4
 
-Bugfixes
+### Bugfixes
 
 - Fix bug where fragments with abstract type conditions were not applied in some cases
 - Correctly serialize default values based on the underlying type for introspection
 
 ## v1.1.3
 
-Bugfixes:
+### Bugfixes
 
 - Fix regression where documents containing multiple operations could not have the operation selected
 - Fix issues with returning union types.
 - Fix bug where field names inside argument errors were not returned in the adapted format.
 
-Mix Tasks:
+### Mix Tasks
 
 - `absinthe.schema.json` now requires schema to be given as an `--schema`
   option, but supports the `:absinthe` `:schema` application configuration
@@ -42,13 +166,13 @@ Mix Tasks:
 
 ## v1.1.2
 
-Bugfixes:
+### Bugfixes
 
 - Include `priv/` in package for `absinthe.schema.json` task.
 
 ## v1.1.1
 
-Bugfixes:
+### Bugfixes
 
 - Variables with input objects and lists inside other input objects work properly.
 
@@ -65,7 +189,7 @@ Absinthe, especially around:
 
 In terms of breaking changes, there is one you should know about:
 
-## Enum values
+### Enum values
 
 As of v1.1.0, Absinthe, by default, adheres to the specification recommendation
 that enum values be provided in ALLCAPS. If you have existing enum definitions
@@ -88,7 +212,7 @@ approach uses macros -- to simplify the visual complexity of schemas, provide
 more comprehensive feedback on correctness, and increase performance, since we
 can now execute any necessary checks and transformations during compilation.
 
-## Type Definitions
+### Type Definitions
 
 Here's an example of an object definition in the _old_ notation style:
 
@@ -143,7 +267,7 @@ In general, attributes of types are now available as nested macros
 function; now you use the singular `field` macro to define each individual
 field).
 
-## Type Modules
+### Type Modules
 
 In the past, this is how you would import types from another module:
 
@@ -193,15 +317,15 @@ The following changes are required if you're upgrading from the previous version
 
 The second argument passed to resolution functions has changed from
 `Absinthe.Execution.t` to a flatter, simpler data structure,
-`Absinthe.Execution.Field.t`. This struct will be a more carefully curated
+`Absinthe.Resolution.t`. This struct will be a more carefully curated
 selection of metadata and match more closely to values in the JS
 reference implementation.
 
-See the typedoc for information about `Absinthe.Execution.Field.t`, and change
+See the typedoc for information about `Absinthe.Resolution.t`, and change
 any advanced resolvers to use this new struct. The most likely change will be
 the use of `source` instead of `resolution.target`.
 
-## v0.4.0
+### v0.4.0
 
 The following changes are required if you're upgrading from the previous version:
 
 
@@ -7,44 +7,69 @@
 
 Goals:
 
-- Complete implementation of the [GraphQL Working Draft](https://facebook.github.io/graphql), dated April 2016.
+- Complete implementation of the [GraphQL Working Draft](https://facebook.github.io/graphql).
 - An idiomatic, readable, and comfortable API for Elixir developers
-- Detailed error messages and documentation
-- A focus on robustness and production-level performance
+- Extensibility based on small parts that do one thing well.
+- Detailed error messages and documentation.
+- A focus on robustness and production-level performance.
 
 Please see the website at [http://absinthe-graphql.org](http://absinthe-graphql.org).
 
-## Features
-
-- Parser
-  - All AST types
-  - Fragments and type conditions
-  - Line number reporting
-  - ~~Column number reporting~~ (Not currently available due to Leex tokenizer constraint)
-- Schema definition
-  - All types (eg, Object, Input Object, Enum, Union, Interface, Scalar)
-  - Circular type references
-  - Support for [custom scalars](http://absinthe-graphql.org/guides/custom-scalars/)
-  - Support for custom directives
-  - Field, argument, and enum value [deprecation](http://absinthe-graphql.org/guides/deprecation/)
-  - Compile-time schema validation
-- [Introspection](http://absinthe-graphql.org/guides/introspection/), compatible with GraphiQL
-- Query execution
-  - General
-  - Named fragments, inline fragments, and fragment spreads with type conditions
-  - `@skip` and `@include` directives
-  - [Adapter](http://absinthe-graphql.org/guides/adapters/) mechanism to support conversion between camelCase query documents
-    and snake_cased schema definition.
-- Client support
-  - Generation of JSON and GraphQL (IDL) introspection documents for use by client frameworks
+## Why Use Absinthe?
+
+Absinthe goes far beyond GraphQL specification basics.
+
+### Easy-to-Read, Fast-to-Run Schemas
+
+Absinthe schemas are defined using easy-to-read macros that build and verify
+their structure at compile-time, preventing runtime errors and increasing
+performance.
+
+### Pluggability
+
+The entire query processing pipeline is configurable. Add, swap out, or remove
+the parser, individual validations, or resolution logic at will, even on a
+per-document basis.
+
+### Advanced Resolution
+
+Absinthe includes a number of advanced resolution features, to include:
+
+- Asynchronous field resolution
+- Batched field resolution (addressing N+1 query problems)
+- A resolution plugin system supporting further extensibility
+
+### Idiomatic Documents, Idiomatic Code
+
+Write your schemas in idiomatic Elixir `snake_case` notation. Absinthe can
+transparently translate to `camelCase` notation for your API clients.
+
+Or, define your own translation scheme by writing an simple adapter.
+
+### Frontend Support
+
+We care about support for third-party frameworks, both on the back and
+front end.
+
+So far, we include specialized support for Phoenix and Plug on the backend,
+and [Relay](https://facebook.github.io/relay/) on the frontend.
+
+Of course we work out of the box with other frontend frameworks and GraphQL
+clients, too.
+
+### An Active Community
+
+The project is under constant improvement by a growing list of contributors,
+and your feedback is important. Please
+[join us](http://absinthe-graphql.org/community/)!
 
 ## Installation
 
 Install from [Hex.pm](https://hex.pm/packages/absinthe):
 
 ```elixir
 def deps do
-  [{:absinthe, "~> 1.1.0"}]
+  [{:absinthe, "~> 1.2.0"}]
 end
 ```
 
@@ -56,7 +81,7 @@ def application do
 end
 ```
 
-Note: Absinthe requires Elixir 1.2 or higher.
+Note: Absinthe requires Elixir 1.3 or higher.
 
 ## Upgrading