Prevent introspection field __typename from being evaluated as an Entity Field

[seantleonard]

Why make this change?

• Closes __typename mistakenly interpreted as table column on gql queries #447
  • GraphQL clients like Apollo and urql implicitly add the GraphQL introspection field __typename to their queries, which is incorrectly evaluated in DAB engine as a database column. This should not be the case.
  • From Apollo documentation:

Every object type in your schema automatically has a field named __typename (you don't need to define it). The __typename field returns the object type's name as a String (e.g., Book or Author).
GraphQL clients use an object's __typename for many purposes, such as to determine which type was returned by a field that can return multiple types (i.e., a union or interface).

What is this change?

• When a field with reserved GraphQL introspection naming is detected (__typename), ignore adding that field as a column in the SqlQueryStructure object. HotChocolate automatically resolved __typename into the proper value in its own engine and our resolver should not be concerned with it.
• With this change, the generated database query is correctly authored as:

SELECT TOP 100 [table0].[id] AS [id] FROM [dbo].[books] AS [table0] WHERE 1 = 1 ORDER BY [table0].[id] ASC FOR JSON PATH, INCLUDE_NULL_VALUES

How was this tested?

• Integration Tests, added for single result / single item query, and a list query where nested fields exist.
• Unit Tests

Sample Request(s)

Request

query myPublisherQuery{
  publishers {
    __typename,
    items{
      __typename,
      name
    }
  }
}

Response

{
  "data": {
    "publishers": {
      "__typename": "PublisherConnection",
      "items": [
        {
          "__typename": "Publisher",
          "name": "The First Publisher"
        },
        {
          "__typename": "Publisher",
          "name": "Big Company"
        },
        {
          "__typename": "Publisher",
          "name": "Policy Publisher 01"
        },
        {
          "__typename": "Publisher",
          "name": "Policy Publisher 02"
        },
        {
          "__typename": "Publisher",
          "name": "TBD Publishing One"
        },
        {
          "__typename": "Publisher",
          "name": "TBD Publishing Two Ltd"
        },
        {
          "__typename": "Publisher",
          "name": "Small Town Publisher"
        }
      ]
    }
  }
}

[ayush3797]

Can a database table actually have a column with name __typename ? Does it mean using graphql we cannot query a column in a table which has a reserved name?

[seantleonard]

Can a database table actually have a column with name __typename ? Does it mean using graphql we cannot query a column in a table which has a reserved name?

Can there be other introspection fields?
Should we extend this to go beyond just typename?

Good point, per GraphQL Specification, we should extend this logic to type references with double underscore (__).

Any Name within a GraphQL type system must not start with two underscores "__" unless it is part of the introspection system as defined by this specification.

Types and fields required by the GraphQL introspection system that are used in the same context as user-defined types and fields are prefixed with "" two underscores. This in order to avoid naming collisions with user-defined GraphQL types.
Otherwise, any Name within a GraphQL type system must not start with two underscores "".

[seantleonard]

SQL allows underscores in column names, so we may need to require aliases be used in our runtime config to enable those fields to be used in our GraphQL Endpoint https://learn.microsoft.com/en-us/sql/odbc/microsoft/column-name-limitations?view=sql-server-ver16

[aaronburtle]

looks good just a nit and possible suggestion.

[yorek]

I think it is fine to require that exposed database columns or documents properties do not start with a double underscore. Make sure this requirement is documented. This shouldn't be big deal as using the mapping feature it will always be possible to change the name of a column or a property to something else.

[Aniruddh25]

LGTM, thanks for the quick fix!

[aaronburtle]

LGTM! Just some nits, and a couple comments about clarifying some large if statements.