Skip to content

Conversation

@bbakerman
Copy link
Member

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

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
@bbakerman bbakerman added this to the 18.0 milestone Sep 7, 2021
};
}

private Integer sortVale(GraphQLNamedSchemaElement e1, Map<String, Integer> namedSortValues) {
Copy link
Member

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
Copy link
Member

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);
Copy link
Member

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.

Copy link
Member Author

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")
Copy link
Member

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?

Copy link
Member Author

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) {
Copy link
Member

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@bbakerman bbakerman modified the milestones: 18.0, 17.3 Sep 18, 2021
@bbakerman bbakerman merged commit 03c6169 into master Nov 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants