-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Inject defaults into the planConnection query in the GTFS GraphQL schema #6339
base: dev-2.x
Are you sure you want to change the base?
Inject defaults into the planConnection query in the GTFS GraphQL schema #6339
Conversation
We need to decide if using a directive makes sense or should we just use the input type and field names as keys for the translations. Also, have to maybe figure out how to not construct the schema on each request. |
Can you resolve the conflicts? |
We need some defaults from the request
* Service for fetching the {@link GraphQLSchema}. The purpose of this class is to avoid | ||
* reconstructing the schema on each request. | ||
*/ | ||
public class SchemaService { |
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 ok that this is just a class or do we need an interface?
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.
Do we even need it at all? If we make the binding @singleton (you already do that) then there should only be a single instance.
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.
@t2gran mentioned in some developer meeting that this should be put in a service but I agree that the service might add an unnecessary layer here.
} catch (Exception e) { | ||
LOG.error("Unable to build GTFS GraphQL Schema", e); | ||
} | ||
return null; |
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.
Should we return null or throw some exception here?
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.
I would throw an exception. Returning null will just cause a more confusing NPE somehwere else.
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.
The schema is built on the first request that comes to the server. I would prefer to build it even before the server starts serving requests so if there is some issue, it could crash the server. Do you have any clue how that could be achieved?
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.
I think you have to call the method eagerly. I believe that Dagger instantiates the dependencies lazily.
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.
What could be a good place to call it eagerly from?
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.
Maybe here?
Lines 155 to 159 in 6ae498d
private Application createApplication() { | |
LOG.info("Wiring up and configuring server."); | |
setupTransitRoutingServer(); | |
return new OTPWebApplication(routerConfig().server(), this::createServerContext); | |
} |
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.
On the other hand, there is already a unit test so I'm not sure how necessary it is.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev-2.x #6339 +/- ##
=============================================
- Coverage 69.85% 69.82% -0.04%
- Complexity 17926 17982 +56
=============================================
Files 2035 2046 +11
Lines 76509 76726 +217
Branches 7825 7835 +10
=============================================
+ Hits 53443 53571 +128
- Misses 20327 20412 +85
- Partials 2739 2743 +4 ☔ View full report in Codecov by Sentry. |
We decided to not use directives (however directive wiring is used to inject the defaults). Used dependency injection to avoid constructing the schema on each request. |
Summary
Inject defaults (either from code or configuration) into the planConnection query in the GTFS GraphQL schema that is outputted through introspection.
This pr also allows to reset
searchWindow
as null in theplanConnection
query (in case it has been configured on server).Issue
No issue
Unit tests
Added tests.
Documentation
In schema
Changelog
From title
Bumping the serialization version id
Not needed