refactor: optimize trip filtering and fix service date calculation#398
Conversation
aaronbrethorst
left a comment
There was a problem hiding this comment.
Elegant simplification, Adel. Replacing a full database round-trip with an in-memory set lookup is exactly the right move here, and the serviceDate fix catches a subtle semantic bug.
What Changed
1. Eliminate GetTripsByServiceID query — Instead of fetching all trips for active service IDs from the database (potentially thousands of rows) just to build a trip ID filter set, the code now builds an activeServiceIDSet directly from the already-available activeServiceIDs slice and filters allStopTimes by st.ServiceID. This is semantically equivalent — a stop time is active iff its service is active — and avoids a costly DB round-trip plus the memory for the full trip result set.
2. Fix serviceDateMillis — Previously computed from params.Time.UnixMilli() (the raw request timestamp, e.g., 14:30:00). Now computed from serviceMidnight.UnixMilli(), which correctly represents midnight of the service day. This matches the semantic meaning of serviceDate in the OBA API response.
Review
No issues found. Both changes are correct, well-motivated, and result in a net reduction of 6 lines. The ServiceID field on GetStopTimesForStopInWindowRow (confirmed in query.sql.go:2643) makes the in-memory filtering straightforward. Existing tests all pass.
|
Hi Aaron, since this is approved, could we get it merged? Thanks! |
|
@3rabiii my bad, sorry! |
Context
This PR addressing suggestions from the previous review regarding
arrivalsAndDeparturesForStopHandler.Changes
serviceDate: UpdatedserviceDateMillisto use the calculatedserviceMidnightinstead of the raw request timestamp. This ensures the date correctly represents midnight of the service day.GetTripsByServiceIDdatabase query which loaded all trips into memory. Instead,stopTimesare now filtered directly usingServiceID(via an O(1) lookup set fromactiveServiceIDs).Impact
serviceDatein the response.@aaronbrethorst
fixes : #397