Releases: graphql-java/graphql-java
9.3
This is a bugfix release to address mainly the following things:
#1191 race conditions in data loader dispatching
#1182 fix null element
#1150 class cast exception in schema generation
#1142 validate input variables
#1113 npe in field tracking during dispatch
#1159 fix json encoding of values
See https://github.com/graphql-java/graphql-java/pulls?q=is%3Apr+milestone%3A9.3
Release 9.2
This releases fixes a single regression from 9.1:
#1118
Release 9.1
This is a bugfix release to address mainly the following things:
#1102: This fixes mutation when used with the batched data loader instrumentation.
#1090: This fixes chained instrumentation.
#1072: Not consistent exception handling across strategies
The full list of changes can be found here:
https://github.com/graphql-java/graphql-java/pulls?q=is%3Apr+milestone%3A9.1+is%3Aclosed
Release 9.0
Data Loader performance has been greatly improved
The performance of graphql.execution.instrumentation.dataloader.DataLoaderDispatcherInstrumentation has been greatly improved. It now tracks which fields are outstanding and how many values are expected for that field. This allows it to optimise when it "dispatches" the underlying data loaders so that they retrieve as much data as possible in one call.
PR: #990
Directive Wiring Support
The new graphql.schema.idl.SchemaDirectiveWiring interface allows you to wire in new behaviour to the SDL built graphql schema via directives that are placed on SDL types and fields.
For example imagine a type such as the following
directive @auth(role : String!) on FIELD_DEFINITION
type Employee
id : ID
name : String!
startDate : String!
salary : Float @auth(role : "manager")
}
You can now wire in data fetcher behaviours that enforce the authorisation access to those specific fields.
PR: #1001
Directives MUST be declared in the schema
If you use a directive in the schema, you now MUST declare it up front and on what places it can apply. This is required by the graphql specification. eg:
directive @length(max: Int = -1) on FIELD_DEFINITION | INPUT_FIELD_DEFINITION
There is an boolean flag that allows you to use the old lenient behaviour but its off by default.
PR: #1006
PropertyDataFetcher has been optimised
The default and most called data fetcher graphql.schema.PropertyDataFetcher has been optimised to make it run faster. It now caches method look ups so that the costs of reflection is not paid over and over
PR: #1013
@defer support is no longer experiemental
It is now considered a supported operation in graphql-java.
PR: #1035
New Traverser for analyzing queries:
QueryTraverser is a new traverser for Documents (or part of it) which tracks at the same time the type
informations of the Schema. It is intended to be used for advanced use-cases including libraries build on top of graphql-java.
PR: #1031
More
See the following Pull Requests for more information on other changes v9.0
Release 8.0
This release contains a number of fixes, enhancements and breaking changes.
The list of breaking changes can be found here
Extend all the SDL types
The graphql SDL specification has finally hit master at Facebook and graphql-java has reflected this.
https://github.com/facebook/graphql/blob/master/spec/Section%203%20--%20Type%20System.md
One new capability is that you can now extend all the different types not just Object types, which includes Interfaces, Unions, Enums, Scalars and Input Objects.
interface NamedEntity {
name: String
}
interface ValuedEntity {
value: Int
}
type Person implements NamedEntity {
name: String
age: Int
}
type Business implements NamedEntity & ValuedEntity {
name: String
value: Int
employeeCount: Int
}
extend interface NamedEntity {
nickname: String
}
extend type Person {
nickname: String
}
extend type Business {
nickname: String
}
See:
Directives on runtime types
You can specify directives during SDL type definition and these have now been captured and transferred to the graphql runtime types.
So for example given
type Person implements NamedEntity {
name: String
age: Int
wage : Int @security(role:"manager")
}
The special directive security will be made available on the wage field.
GraphQLDirective securityDirective = personType.getField("wage).getDirective("security")
See
Instrumentation
The graphql.execution.instrumentation.Instrumentation SPI has been significantly changed. graphql-java uses an asynchronous model to execute a query and Instrumentation and InstrumentationContext has been changed to reflect that.
The signature of the methods have been changed to reflect that instrumentation callbacks now happen in two phases. The first is when the engine first dispatches an operation step and then again when it asynchronously completes.
public interface InstrumentationContext<T> {
/**
* This is invoked when the instrumentation step is initially dispatched
*
* @param result the result of the step as a completable future
*/
void onDispatched(CompletableFuture<T> result);
/**
* This is invoked when the instrumentation step is fully completed
*
* @param result the result of the step (which may be null)
* @param t this exception will be non null if an exception was thrown during the step
*/
void onCompleted(T result, Throwable t);
}This is a breaking change to code that has implemented Instrumentation. You will have to change the code to implement this double callback pattern.
See #894
@fetch directive has been added to SDL
You can now specify an alternative name to fetch property values from during SDL type declaration
type Invoice {
id : ID
invoiceDate : String @fetch(from:"whenInvoiced")
}
This allows indirection between the names you want to use in a graphql schema and the backing Java data
without having to write this mapping logic into all your data fetchers.
Experimental support for deferred execution
You can now support a deferred execution of parts of a query via @defer directive.
(This is an experimental feature, it is currently not part of the official spec.)
The ability to have more than one error per field
The graphql spec is not super clear on whether multiple errors are allowed per field during execution. The previous code took the approach that they are not. However a re-interpretation of the specification reveals that is only true for null field checks.
So the restriction has been lifted and you can have multiple errors per field (except for null checks during execution)
See
#895
Performance improvements during type look up
Our friends from Intuit have contributed a series fo fix to help with the performance of the graphql-java engine during schema type look up, which happens a lot during the execution of a query.
See #898
graphql.execution.batched.BatchedExecutionStrategy has been deprecated
graphql.execution.batched.BatchedExecutionStrategy has been deprecated as an execution strategy.
It does not follow the graphql specification correctly and it has challenges on deeply nested queries with stack overflows being possible. While it remains in the code base, it may be removed at a later time.
See : #965
Other changes and fixes
The rest of the PRs for 8.0 can be found by following this link
https://github.com/graphql-java/graphql-java/pulls?utf8=%E2%9C%93&q=is%3Apr+milestone%3A8.0+
Release 7.0
This release contains a number of fixes and enhancements
The schema diff now reports additions
This will report not just API breaking changes but additions (new fields / arguments etc..) as well
See #870
The root object of the subscription is correctly returned
The original subscription support didn't not send back the top level field which was contrary to the graphql specification. This is now fixed
See #850
Input types can now have field visibility
You can now used field visibility to decide what fields are available on input types as well as output types
see #854
Other changes
Release 6.0
This release includes several improvements and bug fixes.
Subscription support
The big ticket item of 6.0 is support for graphql subscriptions. A subscription is a stream of results sent out by applying a graphql query over changing results.
This explains more : http://graphql.org/blog/subscriptions-in-graphql-and-relay/ in a general sense.
The graphql-java support is based on returning a reactive stream of ExecutionResult. Each time something changes on the subscription a new ExecutionResult is sent down to the Subscriber.
Systems like RxJava have support for the http://www.reactive-streams.org/ interfaces and with Java 9 you can write trivial adaptors to turn reactive stream Subscribers into Java 9 Flow.Subscriberss
See #754
Performance of Data Loader
The efficiency of data loader has be improved. Before it was too eager is calling dispatch which meant that lists of data cause early dispatches. The code has improved to handle this and the data loader batching is delayed into the last possible moment, greatly increasing the batching efficiency
See #764
Validation problems are now errors not exceptions
In line with the reference graphql-js implementation, validation and coercion problems are reported as errors and not exceptions.
See #789
Tracing Support now has parsing and validation timings
The Apollo Tracing spec was updated to include timings for parsing and validation and this is now reflected correctly.
See #784
API enhancements
A small API enhancement to make it easier to use the TypeResolution class as well as the ability to override the exceptions from the query complexity checkers.
There is also more data available via the TypeResolutionEnvironment class.
There is also a new AsyncDataFetcher to help compose asynchronous data fetchers.
See #774
See #778
See #795
See #798
Other fixes include
Release 5.0
This release includes several bugfixes and improvements.
Dataloader support
The most important strategic change is #704: We now include java-dataloader as a direct dependency to make it as easy as possible to tackle performance issues during complex queries.
This also means java-dataloader is now a first class citizen in the graphql java world and will be maintained and improved on the same level as graphql-java.
Breaking change
We also reverted an older change to be graphql specification compliant again regarding InputObjects variables: #750. We expect that some users may have a problem with that. Please open an Issue if that is the case and we will find a solution.
Other improvements
Other notable changes are:
#690: pluggable field validation
#735: DataFetcher factories to allow for better IoC support of data fetchers
#745: diff two schemas
#747: Fix validation of non-null Interface member
#738: more logging of query execution
#708: allow different directives on the same field
#678, #696, #697 : Batched ExecutionStrategy fixes
#681: Support for primitive arrays as a return value for Lists
#679: Support for Iterables for as a return value for Lists
For a full list of issus/PR see here.
Release 4.2
This is bugfix release containing these changes:
https://github.com/graphql-java/graphql-java/milestone/8?closed=1
Release 4.1
This release is a bugfix release for 4.0 with one single PR:
#666: the new QueryTraversal class didn't work with mutations or subscriptions.
Please see here for the full 4.0 release notes: https://github.com/graphql-java/graphql-java/releases/tag/v4.0