-
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
Refetch transit leg with a leg query of GTFS GraphQL API #6045
Refetch transit leg with a leg query of GTFS GraphQL API #6045
Conversation
@binh-dam-ibigroup This might be interesting for you. @vesameskanen I almost cannot believe that it is so easy! |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev-2.x #6045 +/- ##
=============================================
+ Coverage 69.81% 69.83% +0.01%
- Complexity 17418 17460 +42
=============================================
Files 1974 1975 +1
Lines 74537 74624 +87
Branches 7633 7638 +5
=============================================
+ Hits 52040 52115 +75
- Misses 19847 19857 +10
- Partials 2650 2652 +2 ☔ View full report in Codecov by Sentry. |
src/main/java/org/opentripplanner/apis/gtfs/datafetchers/QueryTypeImpl.java
Outdated
Show resolved
Hide resolved
src/main/resources/org/opentripplanner/apis/gtfs/schema.graphqls
Outdated
Show resolved
Hide resolved
This is easy because this was already done in the transmodel API. However, the transmodel API has own legs query for this because it lacks the node query/interface. |
@vesameskanen will still add some integration tests for this. |
GTFS integration tests currently cannot test leg refetching, because mocked itineraries lack essential data used in encoding the leg information. Integration test now tests only that legs contain the id. |
src/main/java/org/opentripplanner/apis/gtfs/datafetchers/LegImpl.java
Outdated
Show resolved
Hide resolved
src/main/resources/org/opentripplanner/apis/gtfs/schema.graphqls
Outdated
Show resolved
Hide resolved
Also, move all encoding/decoding logig to LegReferenceSerializer class.
src/main/java/org/opentripplanner/model/plan/legreference/LegReferenceSerializer.java
Outdated
Show resolved
Hide resolved
I tested new legs with relay and got lots of problems. Relay does not accept nodes with same node id but different content. Either all leg types must be serialized to unique id ('NotAvailable' is not OK), or we have to revert node interface for legs and add a dedicated leg query. Any opinions? |
Maybe I don't get it but don't all legs have the same type in GraphQL? |
@vesameskanen explained to me that the issue is that the non-transit legs all have the same id. We discussed this today and thought maybe the solution would be to generate unique ids based on actual leg data (such as departure/arrival time) even if we don't support refetching based on those ids. I tried adding tests for refetching the legs through the node query in the graphql integration tests on Tuesday but creating/maintaining such test would be slightly difficult. |
src/main/java/org/opentripplanner/apis/gtfs/datafetchers/NodeTypeResolver.java
Outdated
Show resolved
Hide resolved
src/main/resources/org/opentripplanner/apis/gtfs/schema.graphqls
Outdated
Show resolved
Hide resolved
Co-authored-by: Leonard Ehrenfried <mail@leonard.io>
…-leg-node-refetch
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.
We might need to discuss my suggestion in a developer meeting. Idk if we should give entities global ids even if they are not refetchable with a node query. I think at least in netex, the ids are always unique and have the type in the id (if I'm not mistaken).
public DataFetcher<Relay.ResolvedGlobalId> id() { | ||
return environment -> { | ||
var ref = getSource(environment).getLegReference(); | ||
if (ref == null) { | ||
return null; | ||
} | ||
var id = LegReferenceSerializer.encode(ref); | ||
return new Relay.ResolvedGlobalId("Leg", id); | ||
}; |
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 don't think we should use the global id anymore, since we have own query for this now, we can just return a string which is the output of the LegReferenceSerializer.encode(ref)
.
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.
Using plain string is indeed simpler. Changed.
src/main/resources/org/opentripplanner/apis/gtfs/schema.graphqls
Outdated
Show resolved
Hide resolved
src/main/resources/org/opentripplanner/apis/gtfs/schema.graphqls
Outdated
Show resolved
Hide resolved
I think since the leg reference has "SCHEDULED_TRANSIT_LEG_V3" in the id (example base64 decoded id |
We decided to just use the |
src/main/java/org/opentripplanner/apis/gtfs/datafetchers/LegImpl.java
Outdated
Show resolved
Hide resolved
src/main/resources/org/opentripplanner/apis/gtfs/schema.graphqls
Outdated
Show resolved
Hide resolved
…pl.java Co-authored-by: Joel Lappalainen <lappalj8@gmail.com>
Co-authored-by: Joel Lappalainen <lappalj8@gmail.com>
@@ -189,10 +190,12 @@ public DataFetcher<Boolean> realTime() { | |||
return environment -> getSource(environment).getRealTime(); | |||
} | |||
|
|||
// TODO | |||
@Override | |||
public DataFetcher<String> realtimeState() { |
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 just realised that this doesn't use a proper mapper, which I think is a very useful thing.
Since I already approved, I wrote the code myself: leonardehrenfried@a763bc5
If you want you can cherry pick it into this PR.
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.
Ah, too late. I will open another one myself.
My GTFS has an In this case, can it be used to fetch the updated timetable? |
Summary
GTFS leg object now includes a graphql node id . Transit leg can be refetched using a new leg query:
query legQuery { leg(id: "foo") { mode start { estimated { time } } } }
Such query can be used to update an itinerary and to detect if the itinerary is no longer possible because of delays or canceled trips.
Non-transit legs cannot be refetched - the response is always null.
This PR also adds missing implementation for querying leg's realtimeState via GTFS graphql API.
Documentation
In the graphql schema.