Releases: graphql-python/graphql-core-legacy
v0.4.14
Same improvements as GraphQL-js v0.4.14
.
v0.4.13
Same improvements as GraphQL-js v0.4.13
.
graphql-core v0.4.12.1 release
This release is a halfway-point between 0.4.12 and 0.4.13, containing the validation stuff that's been implemented so far.
graphql-core v0.4.12 release
- Added support for experimental schema validation #37.
graphql-core v0.4.11 release
This release updates feature parity to graphql-js
v0.4.11.
Changelog
- Fix typo in directive schema introspection description.
- #32 Implement
concat_ast
utility - #33 Allow providing directives to
GraphQLSchema
- #34 Allow nested objects with similar keys.
- #35 Support deprecation via introspection
- #36 Fix false positive validation error from fragment cycle when unknown fragment is used.
[v0.4.9] graphql-core v0.4.9 release
We're happy to announce graphql-core
v0.4.9 is a stable release and is ready for use in Production.
Changelog
[v0.4.7b1] graphql-core v0.4.7-beta-1 release
Getting ready for stable release.
Changelog:
- [Executor] Implement memoization on
get_argument_values
. - [Type Definition] Implement
__hash__
methods onGraphQLField
andGraphQLArgument
. - [AST Visitor] Check if edit in visitor is a valid node.
- GraphQLUnion shall now accept a callable for types. This will make functionality equivalent to all the other types. i.e. GraphQLInterfaceType and GraphQLObjectType when it comes to defining fields/interfaces/types.
[v0.4.7b0] graphql-core v0.4.7-beta-0 release
This is the first beta release of graphql-core
and represents feature parity with graphql-js
v0.4.7
, hence the matching version number. All graphql-core
releases will follow graphql-js
in terms of version numbers. This means for a given version of graphql-js, you can expect feature parity on the same version of graphql-core
.
We will follow GraphQL's semantic versioning and releases except for one key difference, we will be introducing a BUGFIX version number as well, in the form of MAJOR.MINOR.PATCH.BUGFIX
. This will allow us to match the PATCHes in graphql-js, while maintaining our own bugfix version numbers. That means that v0.4.7.0
, v0.4.7.1
will all match v0.4.7
in feature parity, but with bugfixes to the Python codebase.
Changelog since v0.1a4
- #23 Implement remaining unit
core_type/test_definition
unit tests. - Implement
__eq__
operator onGraphQLField
,GraphQLArgument
andGraphQLInputObjectField
. - Union & Interface
resolve_type
now takes secondaryinfo
argument to matchis_type_of
. - #23 [Execution] Implement abstract execution tests, variable tests, missing list, non null and union interface tests.
- #23 Implement tests for middleware resolver tagging utils, DefaultOrderedDict and additional code branches in async/gevent executor middleware.
- Fix
ResolveInfo.root_value
. - #5 Implement
build_client_schema
utility - #22 Fix issue where input value not being provided would raise a KeyError.
- #21
coerce_string
should return a unicode string always. GraphQLSchema.type_map()
will now return anOrderedDict
.- #25 Sort
fields
,args
andvalues
in GraphQLObjectType, GraphQLInputObjectType and GraphQLEnumValue if they are not an ordered dict.
[v0.1a4] graphql-core v0.1-alpha-4 release
This release implements the Type Validation System (#8)
- Implement type validation and unit tests #8
- Implement
assert_object_implements_interface
#8 - Implement missing enum_type tests.
- Removed submodule
libgraphqlparser
, move everything we need intoscripts
. - Make
generate_ast
work on py3x - Use slots in classes that seem to be instantiated a lot (to save some memory)
[v0.1a3] graphql-core v0.1-alpha-3 release.
Yet again more potentially breaking fixes if you are using the Executor directly.
- Implement the
get_operation_ast
utility. - Implement a way to get/set the default executor that is used when you call
graphql.core.graphql()
orgraphql.core.execute()
. You can do this by callinggraphql.core.executor.{get,set}_default_executor()
- Add the option to specify
map_type
in the Executor. This change allows for you to specify what kind of Map you want to store your result data in. The two recommended options are:dict
(the default). Use this when you don't care about result ordering. For example, you don't care that the order in the fields of your response match the order of the fields in your query. For most cases, this is correct and is the fastest option.collections.OrderedDict
, when you pass something that is an OrderedDict, or a subclass of it, the executor will switch into "strict ordering" mode, which will make it so that the order of the results, match the order they were defined in the query. Concurrent execution will still execute out of order however if you are running aQuery
(but the results will still return in the correct order), you can override this by passingexecute_serially=True
to the executor (which is generally not needed. But exists incase you want to execute serially for whatever reason). Also, mutations will always execute serially.
You can use any other user implemented mapping type as long as it implements the MutableMapping
abstract base type.
- The executor no longer takes
schema
in it's constructor. Instead pass this as the first argument toExecutor.execute()
.