Hide csv param #1279
Merged
Hide csv param #1279
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
These two parameters are not intended to be used by the public yet, so they shouldn't show up in the public API documentation.
Swagger seems to generate API parameters from getter and setter names. Corresponding to the csv_column API parameter, getters and setters are called getCsvColumn and setCsvColumn. This generates an API parameter called csvColumn, that isn't there. Renaming the variable "links" the variable and getters/setters, and the csvColumn parameter vanishes.
While it shouldn't show up in the docs, csv is needed for all API tests to pass. allowableValues on the ApiModelProperty using the Enum doesn't seem to work, so csv will show up in the docs.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request Checklist
have been resolved.
[Unreleased] heading.
I have documented my code using JDocs tags.I have written JUnit tests for any new methods/classes and ensured that they pass.I have created API tests for any new functionality exposed to the API.If changes/additions are made to the ors-config.json file, I have added these to the ors config documentationalong with a short description of what it is for, and documented this in the Pull Request (below).
I have referenced the Issue Number in the Pull Request (if the changes were from an issue).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).
For new features or changes involving the graphbuilding process (i.e. changing encoders, updating theimporter 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.
and why the change was needed.
Information about the changes
Hides the csv_factor and csv_column parameters.
Explanation is found in the commit messages.
Examples and reasons for differences between live ORS routes, and those generated from this pull request
Required changes to ors config (if applicable)