Repository navigation
Instrument usage of ExecutableNormalizedOperationFactory.createExecutableNormalizedOperation #4045
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
base: master
Are you sure you want to change the base?
Changes from 2 commits
d0b2634
6ac9b17
3729496
3a4401f
0ed10be
61400e6
9aa6d72
5b74d1f
7c8b8aa
e9baf2f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| package graphql.execution.instrumentation.parameters; | ||
|
|
||
| import graphql.ExecutionInput; | ||
| import graphql.PublicApi; | ||
| import graphql.execution.instrumentation.Instrumentation; | ||
| import graphql.schema.GraphQLSchema; | ||
|
|
||
| /** | ||
| * Parameters sent to {@link Instrumentation} methods | ||
| */ | ||
| @SuppressWarnings("TypeParameterUnusedInFormals") | ||
| @PublicApi | ||
| public class InstrumentationParsedNormalizedOperation extends InstrumentationExecutionParameters { | ||
| public InstrumentationParsedNormalizedOperation(ExecutionInput executionInput, GraphQLSchema schema) { | ||
| super(executionInput, schema); | ||
| } | ||
| } | ||
|
timward60 marked this conversation as resolved.
Resolved
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -23,7 +23,7 @@ | |
| * An operation consists of a list of {@link ExecutableNormalizedField}s in a parent child hierarchy | ||
| */ | ||
| @PublicApi | ||
| public class ExecutableNormalizedOperation { | ||
| public class ExecutableNormalizedOperation implements ParsedNormalizedOperation { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ahh you are going for a common interface - again I dont think its "parsed" - this is not parsing - parsing has a very specific name in this code base - eg text -> AST elements
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes this bit I expected some discussion. Possibly I should rename the new normalized operation implementation classes to something else then use
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For reference here is the follow up PR (WIP) to enable a config to switch between
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ahh didnt see your replies when I made more naming suggestions
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Leaning towards
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @bbakerman and I had a chat and thinking more about it I am not 100% sure we really want an interface and two different implementations. Not only the naming makes it clear that this is very hard to distinguish ... maybe we really want to have just NormalizedField which is a combination of ENF and the current NF.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see. I will still need an interface internally to allow the switching between ENO and NO for experimental usage, but can hide that. Re the instrumentation do we want a separate method for executable normalized operation and normalized document creation, or should I just create a result container that can hold either types? |
||
| private final OperationDefinition.Operation operation; | ||
| private final String operationName; | ||
| private final List<ExecutableNormalizedField> topLevelFields; | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,13 @@ | ||
| package graphql.normalized; | ||
|
|
||
| import graphql.PublicApi; | ||
|
|
||
| /** | ||
| * A {@link ParsedNormalizedOperation} represents a parsed and normalized operation in GraphQL. | ||
| * It is used to handle the execution of GraphQL operations according to the specification, | ||
| * including merging duplicate fields and handling type detection for fields that may correspond | ||
| * to multiple object types. | ||
| */ | ||
| @PublicApi | ||
| public interface ParsedNormalizedOperation { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. name is hard - but again I dont think this is Parsed - but I am not sure on a name - but I cant help shaking the feeling its not parsed
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Tracking the naming discussion here: https://github.com/graphql-java/graphql-java/pull/4045/files#r2196386356
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. name storming NormalizedOperation + ExecutableNormalizedOperation What is the common name here?
|
||
| } | ||
Uh oh!
There was an error while loading. Please reload this page.