Skip to content

Commit

Permalink
Refactor/union arguments (#304)
Browse files Browse the repository at this point in the history
* Missing copyright headers

* Point to prerelease documentation for 2.0.0 branch

* General housekeeping before release

* Update code comment

* Fix TCK tests broken from merge

* fix(jwt): req.cookies might be undefined

this fix prevents the app from crashing id req.cookies is undefined

* Add scalars earlier in schema augmentation for use in types and interfaces without throwing Error (fixes DateTime relationship properties)

* Changes to accomodate merge from master

* fix: use package json for useragent name and version (#271)

* fix: use package json for useragent name and version

* fix: add userAgent support for <=4.2 and >=4.3 drivers

* config: remove codeowners (#277)

* Version update

* fix(login): avoid confusion caused by secondary button (#265)

* fix: losing params while creating Auth Predicate (#281)

* fix: loosing params while creating Auth Predicate

* fix: typos

* fix: typo

* feat: add projection to top level cypher directive (#251)

* feat: add projection to top level queries and mutations using cypher directive

* fix: add missing cypherParams

* Fix for loss of scalar and field level resolvers (#297)

* wrapCustomResolvers removed in favour of schema level resolver auth injection

* Add test cases for this fix

* Mention double escaping for @cypher directive

* Version update

* checkpoint: commit all changes to date - NOT WORKING

* Committing before merging in 2.0.0 changes

* Union connect and test needs fixing

* Add .huskyrc back

* Reformat schema TCK tests for better diff

* Reorganise schema TCK for better diff

* Create union input types in a map

* Various work, including nested connects and disconnects for unions, fixing a variety of bugs

* Documentation changes

* Fix structure of nested creates for unions, and add tests for nested union mutations

* Fix where input for nested update

* Add integration tests for multiple union create/update

Co-authored-by: gaspard <gaspard@gmail.com>
Co-authored-by: Oskar Hane <oh@oskarhane.com>
Co-authored-by: Daniel Starns <danielstarns@hotmail.com>
Co-authored-by: Neo Technology Build Agent <continuous-integration+build-agent@neotechnology.com>
Co-authored-by: Arnaud Gissinger <37625778+mathix420@users.noreply.github.com>
  • Loading branch information
6 people authored Jul 12, 2021
1 parent b0fe269 commit 45ce973
Show file tree
Hide file tree
Showing 23 changed files with 2,698 additions and 696 deletions.
2 changes: 1 addition & 1 deletion docs/asciidoc/guides/2.0.0-migration/mutations.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@

The most broadly affected area of functionality by the 2.0.0 upgrade are the nested operations of Mutations, to faciliate the mutation of and filtering on relationship properties.

The examples in this section will be based off the following type definitions (which have been migrated over to `@neo4j/graphql` syntax):
The examples in this section will be based off the following type definitions:

[source, graphql]
----
Expand Down
94 changes: 94 additions & 0 deletions docs/asciidoc/guides/2.0.0-migration/unions.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,94 @@
[[rel-migration-unions]]
= Unions

The structure of input types for union queries and mutations have been changed for user friendliness, and a more consistent API.

The examples in this section will be based off the following type definitions:

[source, graphql]
----
type Actor {
name: String!
actedIn: [Production!]! @relationship(type: "ACTED_IN", direction: OUT)
}
type Movie {
title: String!
actors: [Actor!]! @relationship(type: "ACTED_IN", direction: IN)
}
type Series {
title: String!
actors: [Actor!]! @relationship(type: "ACTED_IN", direction: IN)
}
union Production = Movie | Series
----

Essentially, field names which were previously of template `${unionFieldName}_${concreteType}` (for example, "actedIn_Movie") are now an object, with the field name at the top, and the member types under it.

For example, a Mutation which would have previously been:

[source, graphql]
----
mutation {
createActors(
input: [
{
name: "Tom Hiddleston"
actedIn_Movie: {
create: [
{
title: "The Avengers"
}
]
}
actedIn_Series: {
create: [
{
title: "Loki"
}
]
}
}
]
)
}
----

Will now be:

[source, graphql]
----
mutation {
createActors(
input: [
{
name: "Tom Hiddleston"
actedIn: {
Movie: {
create: [
{
node: {
title: "The Avengers"
}
}
]
}
Series: {
create: [
{
node: {
title: "Loki"
}
}
]
}
}
}
]
)
}
----

Note the change in structure for union input, but also the additional `node` level which enables the use of relationship properties. These changes are consistent across all operations, including `where`.
113 changes: 69 additions & 44 deletions docs/asciidoc/type-definitions/unions-and-interfaces.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -5,93 +5,118 @@ Unions and interfaces are abstract GraphQL types that enable a schema field to r

[[type-definitions-unions-and-interfaces-union-types]]
== Union Types
Neo4j GraphQL supports the use of Unions on a `@relationship` field.

=== Example
The following schema defines a `User` type, that has a relationship(`HAS_CONTENT`), of type `[Content]`. `Content` is of type `union` representing either `Blog` or `Post`.
The Neo4j GraphQL Library supports the use of unions on relationship fields. For example, the following schema defines a `User` type, that has a relationship `HAS_CONTENT`, of type `[Content]`. `Content` is of type `union` representing either a `Blog` or a `Post`.

[source, graphql]
----
union Content = Blog | Post
type Blog {
title: String
posts: [Post] @relationship(type: "HAS_POST", direction: OUT)
title: String
posts: [Post] @relationship(type: "HAS_POST", direction: OUT)
}
type Post {
content: String
content: String
}
type User {
name: String
content: [Content] @relationship(type: "HAS_CONTENT", direction: OUT)
name: String
content: [Content] @relationship(type: "HAS_CONTENT", direction: OUT)
}
----

Below you can find some examples of how queries and mutations work with this example.

=== Querying a union
The below query gets the user and their content;

The Neo4j GraphQL Library only returns union members which have inline fragments in your selection set.

For example, the following will return users and only their blogs:

[source, graphql]
----
query GetUsersWithContent {
users {
name
content {
... on Blog {
title
posts {
content
query GetUsersWithBlogs {
users {
name
content {
... on Blog {
title
posts {
content
}
}
}
... on Post {
content
}
}
----

Whilst the query below will return both the blogs and posts of users:

[source, graphql]
----
query GetUsersWithAllContent {
users {
name
content {
... on Blog {
title
posts {
content
}
}
... on Post {
content
}
}
}
}
}
----

=== Creating a union
The below mutation creates the user and their content;

The below mutation creates the user and their content:

[source, graphql]
----
mutation CreateUserAndContent {
createUsers(input: [
{
name: "Dan"
content_Blog: {
create: [
{
node: {
title: "My Cool Blog"
posts: {
create: [
{
node: {
content: "My Cool Post"
}
createUsers(
input: [
{
name: "Dan"
content: {
Blog: {
create: [
{
node: {
title: "My Cool Blog"
posts: {
create: [
{
node: {
content: "My Cool Post"
}
}
]
}
]
}
}
}
]
}
]
}
}
]
) {
users {
name
}
]
) {
users {
name
}
}
}
----


== Interface Types

Using interface types will give you no real database support therefore no; query, update, delete, filter support. But instead used as a language feature to safeguard your schema. Great for when dealing with repetitive or large schemas you can essentially put "The side railings up".
Using interface types will give you no database support, therefore there is no support for querying, updating, deleting, filtering. But instead used as a language feature to safeguard your schema. Great for when dealing with repetitive or large schemas you can essentially put "The side railings up".
Loading

0 comments on commit 45ce973

Please sign in to comment.