Limiting number of results on Union types is not possible

[a-alle]

Description

Given the following type definitions:

typeDefs = gql`
  union Publication = Book | Journal

  type Author {
    name: String!
    publications: [Publication!]! @relationship(type: "WROTE", direction: OUT, properties: "Wrote")
  }

  type Book @queryOptions(limit: { default: 3, max: 5 }) {
    title: String!
    author: [Author!]! @relationship(type: "WROTE", direction: IN, properties: "Wrote")
  }

  type Journal @queryOptions(limit: { default: 3, max: 5 }) {
    subject: String!
    author: [Author!]! @relationship(type: "WROTE", direction: IN, properties: "Wrote")
  }

  interface Wrote {
    words: Int!
  }
`;

there is no way to impose limits on the query results involving union fields.
Below are the 2 cases in which Unions are involved: as connections, and as standard:

1. case Connections
   Both of:

const query1 = gql`
  query {
    authors {
      name
      publicationsConnection {
        edges {
          words
          node {
            ... on Book {
              title
            }
            ... on Journal {
              subject
            }
          }
        }
      }
    }            
  }          
`;

.. and ..

const query2 = gql`
  query {
    authors {
      name
      publicationsConnection(first: 2) {
        edges {
          words
          node {
            ... on Book {
              title
            }
            ... on Journal {
              subject
            }
          }
        }
      }
    }
  }
        `;

Result in:

"MATCH (this:\`Author\`)
            CALL {
                WITH this
                CALL {
                    WITH this
                    MATCH (this)-[this_connection_publicationsConnectionthis0:WROTE]->(this_Book:\`Book\`)
                    WITH { words: this_connection_publicationsConnectionthis0.words, node: { __resolveType: \\"Book\\", title: this_Book.title } } AS edge
                    RETURN edge
                    UNION
                    WITH this
                    MATCH (this)-[this_connection_publicationsConnectionthis1:WROTE]->(this_Journal:\`Journal\`)
                    WITH { words: this_connection_publicationsConnectionthis1.words, node: { __resolveType: \\"Journal\\", subject: this_Journal.subject } } AS edge
                    RETURN edge
                }
                WITH collect(edge) AS edges
                WITH edges, size(edges) AS totalCount
                RETURN { edges: edges, totalCount: totalCount } AS this_publicationsConnection
            }
            RETURN this { .name, publicationsConnection: this_publicationsConnection } as this"

! Notice he resulting Cypher does not contain any LIMIT.
It's fair to conclude that both @queryOptions and first are ignored.

2. case standard:

const query3 = gql`
  {
     authors {
       publications {
         ... on Book {
           title
         }
         ... on Journal {
           subject
         }
       }
     }
  }
`;

Results in:

            "MATCH (this:\`Author\`)
            CALL {
                WITH this
                CALL {
                    WITH this
                    MATCH (this)-[thisthis0:WROTE]->(this_publications:\`Book\`)
                    WITH this_publications  { __resolveType: \\"Book\\",  .title } AS this_publications
                    RETURN this_publications AS this_publications
                    UNION
                    WITH this
                    MATCH (this)-[thisthis1:WROTE]->(this_publications:\`Journal\`)
                    WITH this_publications  { __resolveType: \\"Journal\\",  .subject } AS this_publications
                    RETURN this_publications AS this_publications
                }
                WITH this_publications
                RETURN collect(this_publications) AS this_publications
            }
            RETURN this { publications: this_publications } as this"

However,

const query4 = gql`
{
  authors {
    publications(options: { limit: 1 }) {
      ... on Book {
        title
      }
      ... on Journal {
        subject
      }
    }
  }
}
`;

does create a LIMIT:

"MATCH (this:\`Author\`)
            CALL {
                WITH this
                CALL {
                    WITH this
                    MATCH (this)-[thisthis0:WROTE]->(this_publications:\`Book\`)
                    WITH this_publications  { __resolveType: \\"Book\\",  .title } AS this_publications
                    RETURN this_publications AS this_publications
                    UNION
                    WITH this
                    MATCH (this)-[thisthis1:WROTE]->(this_publications:\`Journal\`)
                    WITH this_publications  { __resolveType: \\"Journal\\",  .subject } AS this_publications
                    RETURN this_publications AS this_publications
                }
                WITH this_publications
                **LIMIT 1**
                RETURN collect(this_publications) AS this_publications
            }
            RETURN this { publications: this_publications } as this"

Further on the topic,

• options: { limit: 6 } result in a LIMIT 6 - passing over type Book's max
• options: { limit: 12 } result in a LIMIT 12 - passing over type Book and Journal's combined max

It's then fair to conclude that @queryOptions is ignored, and only the options: { limit } is really taken into account.

Problem

There should be a way to limit the nr of results returned by querying on Union types, and it should be uniform across both connection & standard cases.

Solution

1. support the @queryOptions defined on each type that is part of a Union. ✅
2. combine the @queryOptions of the types (default and max) as expected from a Union of these types.
3. both types should maintain their own options in the Cypher subquery that resolves them.
4. options: {limit} for standard and first for connections should be compared and taken into account with the combined queryOptions in the generation of the final limit.
5. Specifying a larger limit than the queryOptions.max of the Union should not result in a LIMIT of more than queryOptions.max.
6. [Open Question: Smaller limit]
7. [Open Question: Sorting]

Proposed Solution

Given the following simplified type definitions:

  union Publication = Book | Journal
  type Book @queryOptions(limit: { default: 2, max: 7 }) {...}
  type Journal @queryOptions(limit: { default: 4, max: 9 }) {...}

The proposed approach (illustrated for the Union type Publication):

• default = the sum of all type's default: 2 + 4 = 6
• max = the sum of all type's max: 7 + 9 = 16
  Each type limits at the subquery level with their own default and max value the nr of results.
  By default, the Publication would contain 2 Books and 4 Journals.

Open questions

1. Do we allow sorting? How would that work if Book has title and Journal has subject?
2. How would specifying a smaller limit than queryOptions.default of the Union type work? One of the types should be prioritized? In what order?

[darrellwarde]

All in all, I think we should treat this work from a "bug fix" standpoint for now. Let's fix the things where they aren't working as you would expect, but let's try not to add too many features at this stage. Union and Interface support needs a large review, and I think any new features here should come under that remit.

As for the open questions:

• Do we allow sorting? How would that work if Book has title and Journal has subject?

Sorting for Union type relationships is currently not supported, but if it was, then you would sort Books and Journals individually, and there would be no way to sort the entire list.

• How would specifying a smaller limit than queryOptions.default of the Union type work? One of the types should be prioritized? In what order?

I think for this question it's important to consider the order in which the limits are applied, and just apply sensible logic on top of that. So the Union limits for each type get applied first, say 6 + 6 so twelve results, and then the limit for the whole Union gets applied, say at 10, which strips off two of the results returned from the Union subqueries. Regarding order, we should investigate whether the order in which they are in the selection set reliably results in the order of the Cypher or not.

[MichaelCDormann]

Let's fix the things where they aren't working as you would expect

Hi, any movement on this? I realized there isn't a way to paginate through union types, which makes using union types in some cases a little painful

[neo4j-team-graphql]

Many thanks for raising this bug report @a-alle. 🐛 We will now attempt to reproduce the bug based on the steps you have provided.

Please ensure that you've provided the necessary information for a minimal reproduction, including but not limited to:

• Type definitions
• Resolvers
• Query and/or Mutation (or multiple) needed to reproduce

If you have a support agreement with Neo4j, please link this GitHub issue to a new or existing Zendesk ticket.

Thanks again! 🙏

[neo4j-team-graphql]

We've been able to confirm this bug using the steps to reproduce that you provided - many thanks @a-alle! 🙏 We will now prioritise the bug and address it appropriately.