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

feat: config migration and graph repo client #1889

Merged
merged 63 commits into from
Nov 28, 2024
Merged

Conversation

MichaelsJP
Copy link
Member

@MichaelsJP MichaelsJP commented Nov 8, 2024

Pull Request Checklist

  • 1. I have rebased the latest version of the main branch into my feature branch and all conflicts
    have been resolved.
  • 2. I have added information about the change/addition to functionality to the CHANGELOG.md file under the
    [Unreleased] heading.
  • 3. I have documented my code using JDocs tags.
  • 4. I have removed unnecessary commented out code, imports and System.out.println statements.
  • 5. I have written JUnit tests for any new methods/classes and ensured that they pass.
  • 6. I have created API tests for any new functionality exposed to the API.
  • 7. If changes/additions are made to the ors-config.json file, I have added these to the ors config documentation
    along with a short description of what it is for, and documented this in the Pull Request (below).
  • 8. I have built graphs with my code of the Heidelberg.osm.gz file and run the api-tests with all test passing
  • 9. I have referenced the Issue Number in the Pull Request (if the changes were from an issue).
  • 10. For new features or changes involving building of graphs, I have tested on a larger dataset
    (at least Germany), and the graphs build without problems (i.e. no out-of-memory errors).
  • 11. For new features or changes involving the graphbuilding process (i.e. changing encoders, updating the
    importer etc.), I have generated longer distance routes for the affected profiles with different options
    (avoid features, max weight etc.) and compared these with the routes of the same parameters and start/end
    points generated from the current live ORS.
    If there are differences then the reasoning for these MUST be documented in the pull request.
  • 12. I have written in the Pull Request information about the changes made including their intended usage
    and why the change was needed.
  • 13. For changes touching the API documentation, I have tested that the API playground renders correctly.

Fixes # .

Information about the changes

  • Key functionality added:
  • Reason for change:

Examples and reasons for differences between live ORS routes, and those generated from this pull request

Required changes to ors config (if applicable)

@MichaelsJP MichaelsJP changed the title Feat/graph repo client feat: graph repo client Nov 8, 2024
@MichaelsJP MichaelsJP changed the title feat: graph repo client feat: config migration and graph repo client Nov 8, 2024
@github-actions github-actions bot added feature and removed feature labels Nov 8, 2024
This was referenced Nov 8, 2024
@MichaelsJP MichaelsJP linked an issue Nov 8, 2024 that may be closed by this pull request
@MichaelsJP MichaelsJP removed a link to an issue Nov 8, 2024
@sfendrich
Copy link
Contributor

The commit message title of commit 6035301 is irritating. A refactoring is not supposed to be a breaking change.

@TheGreatRefrigerator
Copy link
Contributor

The commit message title of commit 6035301 is irritating. A refactoring is not supposed to be a breaking change.

The ! indicates a breaking change & the body describes the thing that is breaking:

BREAKING CHANGE: Structural changes in the configuration make this change incompatible with earlier versions and configurations.

according to the specification we are currently using, that's how a breaking change should be committed and it can be on any commit type:
https://www.conventionalcommits.org/en/v1.0.0/#examples

Or do you think the actual title confusing?
refactor the config classes into a separate structure into ors-engine
Would you suggest a different one?

@sfendrich
Copy link
Contributor

No, I think that in general "refactor" and "BREAKING CHANGE" are incompatible by their definition. I wonder whether there are rare exceptions to this?
As the commit changes the behavior it is either a fix or a feat.

@TheGreatRefrigerator
Copy link
Contributor

ah due to refactoring being defined by "not altering existing functionality" 😓. Yeah, agreed.
How about:
feat(config)!: Move the config classes into a separate structure into ors-engine

Copy link
Contributor

@sfendrich sfendrich left a comment

Choose a reason for hiding this comment

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

This is only a partial review suggesting some improvements. The PR is too large to conduct a full review.

Copy link
Contributor

@sfendrich sfendrich left a comment

Choose a reason for hiding this comment

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

Partial review.

Copy link
Contributor

@sfendrich sfendrich left a comment

Choose a reason for hiding this comment

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

A few more comments

@jhaeu jhaeu marked this pull request as ready for review November 28, 2024 12:05
@github-actions github-actions bot added feature and removed feature labels Nov 28, 2024
@MichaelsJP MichaelsJP requested a review from jhaeu November 28, 2024 12:06
@github-actions github-actions bot added feature and removed feature labels Nov 28, 2024
MichaelsJP and others added 18 commits November 28, 2024 13:31
This was called like this for quite some time already. Just streamlining it.
This includes classes, fields, variables, unneeded comments and resolved todos etc.
We need the wrapped one to properly work with jackson config serialization.
We already throw a custom exception. The signature didn't reflect this.
These if statements are trivial and should be merged.
…sEmpty()

Now even the Map.of() check validates to true. Yay!
This makes the intended use more visible and clear that this class doesn't "manage" anything but is used to manage.

co-authored: jhaeu <[email protected]>
The refactor also includes a change for the graph build file from `graph_info.yml` to `graph_build_info.yml`.

co-authored: jhaeu <[email protected]>
@jhaeu jhaeu force-pushed the feat/graph-repo-client branch from e0623aa to 11f2b07 Compare November 28, 2024 12:35
Copy link
Contributor

@jhaeu jhaeu left a comment

Choose a reason for hiding this comment

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

LGTM

@MichaelsJP MichaelsJP marked this pull request as draft November 28, 2024 12:49
@MichaelsJP MichaelsJP marked this pull request as ready for review November 28, 2024 12:49
@github-actions github-actions bot added feature and removed feature labels Nov 28, 2024
@MichaelsJP MichaelsJP enabled auto-merge November 28, 2024 12:50
@MichaelsJP MichaelsJP force-pushed the feat/graph-repo-client branch from c1be5ca to 24bfd2e Compare November 28, 2024 13:17
Copy link

sonarcloud bot commented Nov 28, 2024

@MichaelsJP MichaelsJP merged commit 611facb into main Nov 28, 2024
32 checks passed
@MichaelsJP MichaelsJP deleted the feat/graph-repo-client branch November 28, 2024 13:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants