Skip to content
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

Siri file loader #5460

Merged
merged 7 commits into from Oct 31, 2023
Merged

Siri file loader #5460

merged 7 commits into from Oct 31, 2023

Conversation

t2gran
Copy link
Member

@t2gran t2gran commented Oct 27, 2023

Summary

Add support for loading xml files for Siri SX and EX updates. This feature make it much simpler to test realtime updates. This PR also has a few minor improvements and code cleanup.

Always commit the first update after a long break

In a busy updater it does not matter if we commit early or late, as long as we throttle the update commits to happen with a given frequency. But, when testing OTP manually, it is easy to do mistakes and assume that an update is applied when you
see (log):

INFO 1 of 1 update messages were applied successfully (success rate: 100.0%)

In OTP before this commit, the update was not committed, waiting to fill up the "buffer", and if not other update was applied - nothing happened.

File loader

Use the url to set a directory. The updater will use the directory instead of connecting to a http resource. The file loader will look for xml files: *.xml in the configured directory. The files are renamed by the loader when possessed:

    update.xml  ➞  update.xml.inProgress  ➞  update.xml.ok  or  update.xml.failed

Issue

No.

Unit tests

No.

Documentation

Changelog

No

Bumping the serialization version id

No

In a busy updater it does not matter if we commit early or late, as long as we
throttle the commit to happen with a given frequency. But, when testing OTP
manually, it is easy to do mistakes and assume that an update is applied when you
see "INFO 1 of 1 update messages were applied successfully (success rate: 100.0%)".
In OTP before this commit, the update was not committed, waiting to fill up the
"buffer", and if not other update was applied - nothing happened.
This feature make it much simpler to test realtime updates.
@t2gran t2gran added this to the 2.5 (next release) milestone Oct 27, 2023
@t2gran t2gran requested a review from a team as a code owner October 27, 2023 15:59
@codecov
Copy link

codecov bot commented Oct 27, 2023

Codecov Report

Attention: 134 lines in your changes are missing coverage. Please review.

Comparison is base (8df18db) 66.87% compared to head (4f81133) 66.85%.
Report is 122 commits behind head on dev-2.x.

❗ Current head 4f81133 differs from pull request most recent head 1bce429. Consider uploading reports for the commit 1bce429 to get more accurate results

Additional details and impacted files
@@              Coverage Diff              @@
##             dev-2.x    #5460      +/-   ##
=============================================
- Coverage      66.87%   66.85%   -0.03%     
  Complexity     15504    15504              
=============================================
  Files           1800     1802       +2     
  Lines          69817    69856      +39     
  Branches        7359     7359              
=============================================
+ Hits           46692    46699       +7     
- Misses         20666    20697      +31     
- Partials        2459     2460       +1     
Files Coverage Δ
...tripplanner/ext/fares/impl/DefaultFareService.java 94.44% <100.00%> (+2.21%) ⬆️
...pplanner/ext/fares/model/FareAttributeBuilder.java 72.41% <ø> (-0.76%) ⬇️
...er/ext/flex/template/FlexAccessEgressTemplate.java 71.42% <ø> (ø)
...tripplanner/ext/geocoder/EnglishNGramAnalyzer.java 100.00% <100.00%> (ø)
...pentripplanner/ext/geocoder/StopClusterMapper.java 96.55% <100.00%> (ø)
...ner/ext/transmodelapi/mapping/TransitIdMapper.java 71.87% <100.00%> (ø)
...ntripplanner/ext/traveltime/IsochroneRenderer.java 0.00% <ø> (ø)
...ntripplanner/framework/geometry/GeometryUtils.java 75.18% <ø> (ø)
...ntripplanner/framework/geometry/WgsCoordinate.java 90.56% <100.00%> (ø)
...ripplanner/framework/tostring/ToStringBuilder.java 100.00% <100.00%> (ø)
... and 55 more

... and 10 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

lassetyr
lassetyr previously approved these changes Oct 30, 2023
Siri updates = updateSource.getUpdates();
if (updates != null) {
var updates = updateSource.getUpdates();
if (updates.isPresent()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I think that Optional is great, I'm not a huge fan of the combination of isPresent and get.

I think you should restructure the code a bit so that you can use map() instead. If you agree that this is the way to go, you can cherry-pick this commit: leonardehrenfried@5e8f239

Copy link
Member Author

@t2gran t2gran Oct 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am sorry I don´t find your suggestion readable. Big blocks of code inside a call chain is not recommended. Second, the block is also not a function - it updates the state of the class.

long t1 = System.currentTimeMillis();
try {
Siri siri = siriHttpLoader.fetchSXFeed(requestorRef);
Optional<Siri> siri = siriHttpLoader.fetchSXFeed(requestorRef);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, I would use flatMap() here which saves you dealing with the empty case: leonardehrenfried@873b5b7

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Introducing the flatMap is mentally much harder than to step through the logic and return in each case. I think the fact that your code does not work - and that the error is hard to spot proves my point.

There is a a few advanced programming techniques I personally would love to us in OTP - but I don´t, because we struggle to even follow the basic ones (encapsulation, single-responsibility, same-level-of-abstraction, DRY ...). I try to stick to the what is already use. OO programming techniques are very important in OTP because it matches the problem we are trying to solve. Functional programming is a nice tool, but it does not go well with the imperative code we have (we do agree on removing the imperative code). For example I do not want to pass Optional into methods, and we have a lot passing data down a deep call stack. So, it the return value is passed on, not acted on, then it does not make sense to return an Optional.

Using map to avoid dealing with empty might be a trick in functional programming - but it does not clearly show the intent, and to me looks more like a hack. I would love to use more Domain Driven Design, and then you would not use Optional type at all - you would create your own types witch uses the domain language to clearly state the intent.

Copy link
Member

@leonardehrenfried leonardehrenfried left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please have a look at my requests.

Co-authored-by: Leonard Ehrenfried <mail@leonard.io>
@leonardehrenfried
Copy link
Member

You need to regenerate the docs.

@t2gran t2gran merged commit ba65e63 into opentripplanner:dev-2.x Oct 31, 2023
5 checks passed
@t2gran t2gran deleted the siri-file-loader branch October 31, 2023 16:29
t2gran pushed a commit that referenced this pull request Oct 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants