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
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. |
optionsome
changed the title
|
I'm in process of adding some array and input object defaults as it seems like using them is possible (I thought for some reason that using them wasn't possible). However, I'm slightly struggling with how to deal with resetting This is what the bicycle rental preferences look like currently, for example: Details"Preferences related to bicycle rental (station based or floating bicycle rental)."
input BicycleRentalPreferencesInput {
"Rental networks which can be potentially used as part of an itinerary."
allowedNetworks: [String!]
"Rental networks which cannot be used as part of an itinerary."
bannedNetworks: [String!]
"""
Is it possible to arrive to the destination with a rented bicycle and does it
come with an extra cost.
"""
destinationBicyclePolicy: DestinationBicyclePolicyInput
}
We could add a new field to resetting the Details"Preferences related to bicycle rental (station based or floating bicycle rental)."
input BicycleRentalPreferencesInput {
"Rental networks which can be potentially used as part of an itinerary."
filter: RentalFilter = {allowedNetworks: ["x", "y"]}
"""
Is it possible to arrive to the destination with a rented bicycle and does it
come with an extra cost.
"""
destinationBicyclePolicy: DestinationBicyclePolicyInput
}
On the other hand, adding a new filter implementation always feels like a bit sketchy as usually we end up implementing either something too simple or too complex. What if we want to some filter criteria in the future which is complimentary, like propulsion type in combination of networks (i.e. "x" network's HUMAN propulsion type vehicles are allowed). |
ab98348
| | [maxDirectStreetDuration](#rd_maxDirectStreetDuration) | `duration` | This is the maximum duration for a direct street search for each mode. | *Optional* | `"PT4H"` | 2.1 | | ||
| | [maxJourneyDuration](#rd_maxJourneyDuration) | `duration` | The expected maximum time a journey can last across all possible journeys for the current deployment. | *Optional* | `"PT24H"` | 2.1 | | ||
| | modes | `string` | The set of access/egress/direct/transit modes to be used for the route search. | *Optional* | `"TRANSIT,WALK"` | 2.0 | | ||
| | modes | `string` | The set of access/egress/direct/transfer modes (separated by a comma) to be used for the route search. | *Optional* | `"WALK"` | 2.0 | |
There was a problem hiding this comment.
While testing some changes I noticed we don't actually support providing default transit modes in config.
| } | ||
|
|
||
| public static GraphQLTypes.GraphQLTransitMode map(TransitMode mode) { | ||
| return switch (mode) { |
There was a problem hiding this comment.
Where did these mappers live beforehand?
There was a problem hiding this comment.
For some reason I forgot to check and there was already one, but I removed it in favor of this in ef7018a. However, the previous version had null checks which I'm not sure are necessary as the route mode doesn't seem to be nullable.
3 participants
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
searchWindowas null in theplanConnectionquery (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