| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Sorry, something went wrong.
|
Sorry, something went wrong.
|
Sorry, something went wrong.
|
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This PR contains the following updates:
Release Notes
graphql-java/graphql-java (com.graphql-java:graphql-java)v26.1: 26.1
26.1
This is a bugfix release for 26.
It contains a couple of fixes and no breaking changes.
List of PRs
Full Changelog: graphql-java/graphql-java@v26.0...v26.1
v26.0: 26.0
Compare Source
This is the 26.0 release of graphql-java. Highlights are summarized below; the full list of merged PRs is at the end.
⚠️ Breaking Changes
Query complexity limits are now enforced by default
New QueryComplexityLimits validation checks maxDepth (default 100) and maxFieldsCount (default 100,000) as part of standard validation. Queries exceeding these limits will now fail with new MaxQueryDepthExceeded / MaxQueryFieldsExceeded validation errors.
Introduced in #4256.
Validation rule filtering API changed
In #4228 the rule-filter predicate changed from Predicate<Class<?>> to Predicate<OperationValidationRule> in Validator.validateDocument(...) and ParseAndValidate.parseAndValidate(...). Callers that filtered by class (e.g. rule -> rule != NoUnusedFragments.class) must migrate to the enum (rule -> rule != OperationValidationRule.NO_UNUSED_FRAGMENTS). The @Internal classes AbstractRule and RulesVisitor were removed.
Built-in directive handling consolidated (#4229)
OneOf inhabitability validation (#4248)
New validator rejects OneOf input types that cannot be populated with a finite value (e.g. input A @oneOf { a: A }). Schemas that previously validated may now be rejected.
Non-null field validation for code-built schemas (#4194)
Code-built schemas now perform the same deprecated-on-non-null field validation as SDL-built ones. Schemas relying on the gap may now fail validation.
GraphQLSchema.getCodeRegistry() is no longer @Nullable (#4247)
The return type was incorrectly annotated nullable. Callers may now drop redundant null checks; downstream nullness tooling will reflect the change.
JSpecify nullability annotations rolled out broadly
Waves 2 and 3 (#4184, #4274) plus many individual PRs annotated hundreds of classes across graphql.analysis, graphql.execution, graphql.language, graphql.schema and others with @NullMarked/@NullUnmarked/@Nullable. Kotlin and other null-aware callers will now see stricter nullability contracts; code that relied on previously-permissive signatures may need adjustment.
✨ New Features
⚡ Performance
🐛 Other Noteworthy Changes
Execution / data fetching
Schema / field visibility
Build / packaging / security
Tooling / DX
Full PR list
Expand to see all merged PRsNew Contributors
Full Changelog: graphql-java/graphql-java@v25.0...v26.0
v25.1: 25.1
Compare Source
This is a bugfix release for the 25 version of GraphQL Java
v25.0: 25.0
Compare Source
Key changes
Dataloader
Refactoring strategy
The existing PerLevelDataLoaderStrategy has been refactored which lead to simplifications and performance improvements.
New strategies
Two new strategies were introduced: CHAINED and EXHAUSTED. Both can be configured via UnusalConfiguration (see next section).
CHAINED allow for chained DataLoaders to be used while keeping a per level dispatch strategies.
EXHAUSTED is a completely new strategy that works on the basis to dispatch once the engine is not busy. It mirrors the JS data loader dispatch strategy, but for a multi threaded system.
Unusual Configuration
A more generalised configuration mechanism has been added for "unusual configuration". By that we mean configuation we dont expect many people to use but if they do its now in a more common place
For example if you wanted to change the maximum depth the document parser will accept you could call the following methods.
var parserOptions = newParserOptions().maxRuleDepth(99).build() GraphQL.unusualConfiguration().parsing().setDefaultParserOptions(parserOptions)JSpecify Annotations
The team are starting to embrace https://jspecify.dev/ annotations as the way to indicate nullable and non nullable fields. Many important classes have had these annotations added to help make it more semantically clear when a value can be null or not.
Breaking Changes
A wrapping FetchedValue object is not always returned on field fetchers for performance reasons. This means that graphql.execution.instrumentation.parameters.InstrumentationFieldCompleteParameters#getFetchedObject was created to replace the older getFetchedValue method and the returns object can sometimes be a FetchedValue or sometimes a simple POJO value.
Performance improvements
A series of performance improvements have been made to reduce the memory footprint of the library. Also the Java .stream() operator can be slower than a more direct loop and many of these calls have been changed for performance reasons.
What's Changed
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.