-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Support for tracking the parse order #2539
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This provides a tracker class that remembers the order of elements as they were parsed. This could then be used by a print a schema in parse order
| }; | ||
| } | ||
|
|
||
| private Integer sortVale(GraphQLNamedSchemaElement e1, Map<String, Integer> namedSortValues) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: sortValue
| int sortVal2 = sortVale((GraphQLNamedSchemaElement) e2, namedSortValues); | ||
| return Integer.compare(sortVal1, sortVal2); | ||
| } | ||
| return -1; // sort to the top |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible that neither elements are GraphQLFieldDefinition, GraphQLInputObjectField, GraphQLEnumValueDefinition or GraphQLNamedSchemaElement?
Because in that case the outcome of the comparator would be conflicting.
i.e. both compare(x, y) and compare(y, x) would be -1.
| return Optional.of(handleReDefinition(olderEntry, newEntry)); | ||
| } else { | ||
| target.put(name, newEntry); | ||
| schemaParseOrder.addDefinition(newEntry); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's really hard, at least for me, to judge if we're calling addDefinition in all the correct places. Seems to me that this is quite fragile too, like if we change the code and start parsing types differently, we could easily forget to call schemaParseOrder.addDefinition in the right place.
Maybe it's because I'm not too familiar with the code, but just wanted to pointed that out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah its a good point - 80% of the different types go through the same define or defineExt but there are these exceptions
| "the query type" | ||
| type Q { | ||
| field( arg : String! = "default") : FieldType @deprecated(reason : "no good") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, the comparator doesn't sort fields, but getInOrder does it, correct? Perhaps we could add some more fields in this test and assert the order is preserved?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
getInOrder gives back the SDLDefinition in the order of parsing
The comparator allows a runtime set of types to be sorted back on the parsed order (eg not SDLDefintions AST things but runtime type)
| * | ||
| * @return this {@link SchemaParseOrder} for fluent building | ||
| */ | ||
| public <T extends SDLDefinition<?>> SchemaParseOrder removedDefinition(T sdlDefinition) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo (I think): should be removeDefinition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
This provides a tracker class that remembers the order of elements
as they were parsed.
This could then be used by a print a schema in parse order say