Clarify spec in regard to fields #226
Description
The spec is somewhat unclear as to what exactly should become a field in the GraphQL schema.
In the Fields-section, only fields (of java-objects) are mentioned to be fields in the corresponding graphql-object, which would exclude getters/setters without backing fields and ignore visibility:
Fields in GraphQL are similar to fields in Java in that they are a child of a single entity. Thus, Java fields on entity classes are, by default, GraphQL fields of that entity.
It should be clarified, what is considered to be a field in the GraphQL-type, and wether getter/setter or direct field-access is used to access the property. Ideally, handling of transient and static fields/getters/setters would be also specified.
I would propose, that each public accessible, non-static, non-transient property (public getter/setter with or without field, or public field) is added to the schema as a field.
static would work with the same semantics like @Ignore. transient would work like @Ignore on a field. final on a public field would ignore this field for the input-type (like @Ignore on a setter).
This behaviour should be equal to Jsonb (correct me if I'm wrong) and thus consistent with usage of Jsonb-annotations in mp-graphql, and would lower the barrier of transition from a rest to a graphql-api, since entities behave the same in both.
None of this should break the current tck, no existing test-case would need to be changed.
I don't know if this would mean a breaking change for different implementations, I only know about smallrye-graphql where the behaviour changed from "all fields with getter/setter" in 1.0.0 to "all getters/setters regardless of fields" in the new (unreleased) version. And since it uses Jsonb internally, I suspect some errors with static/transient fields of input-types, which are added to the schema, but ignored at execution (but I haven't tested this)