A new approach for deciding which union members to return!

[darrellwarde]

Description

Excerpt from documentation which explains the change in detail:

Which union members are returned by a Query are dictated by the where filter applied.

For example, the following will return all user content, and you will specifically get the title of each blog.

query GetUsersWithBlogs {
    users {
        name
        content {
            ... on Blog {
                title
            }
        }
    }
}

Whilst the query below will only return blogs. We could for instance use a filter to check that the title is not null to essentially return all blogs:

query GetUsersWithAllContent {
    users {
        name
        content(where: { Blog: { title_NOT: null }}) {
            ... on Blog {
                title
            }
        }
    }
}

Conceptually, this maps to the WHERE clauses of the subquery unions in Cypher. Going back to the first example with no where argument, each subquery has a similar structure:

CALL {
    WITH this
    OPTIONAL MATCH (this)-[has_content:HAS_CONTENT]->(blog:Blog)
    RETURN { __resolveType: "Blog", title: blog.title }
UNION
    WITH this
    OPTIONAL MATCH (this)-[has_content:HAS_CONTENT]->(journal:Post)
    RETURN { __resolveType: "Post" }
}

Now if we were to leave both subqueries and add a WHERE clause for blogs, it would look like this:

CALL {
    WITH this
    OPTIONAL MATCH (this)-[has_content:HAS_CONTENT]->(blog:Blog)
    WHERE blog.title IS NOT NULL
    RETURN { __resolveType: "Blog", title: blog.title }
UNION
    WITH this
    OPTIONAL MATCH (this)-[has_content:HAS_CONTENT]->(journal:Post)
    RETURN { __resolveType: "Post" }
}

As you can see, the subqueries are now "unbalanced", which could result in massive overfetching of Post nodes.

So, when a where argument is passed in, we only include union members which are in the where object, so it is essentially acting as a logical OR gate, different from the rest of our where arguments:

CALL {
    WITH this
    OPTIONAL MATCH (this)-[has_content:HAS_CONTENT]->(blog:Blog)
    WHERE blog.title IS NOT NULL
    RETURN { __resolveType: "Blog", title: blog.title }
}

Issue

This is a new approach for the following PRs, which don't make so much sense for the new count queries and connection totalCount:

• Only return union members which have fragments in the selection set #289
• Bugfix/union member projection #312

Checklist

The following requirements should have been met (depending on the changes in the branch):

• Documentation has been updated
• TCK tests have been updated
• Integration tests have been updated
• Example applications have been updated
• New files have copyright header
• CLA (https://neo4j.com/developer/cla/) has been signed

[danstarns]

All good, I just added two comments on the comments(meta).