Conversation
- Reword generic comments to not mention pelvis specifically
- Add template URL construction: template_{bonesetId}.json
- Add comprehensive test documentation for multi-boneset support
- Maintain SSRF prevention with isValidBoneId() validation
Allows new bone sets to be easily added by following the GitHub directory structure convention without code changes.
leandrumartin
left a comment
There was a problem hiding this comment.
While I like the approach you took to configuring the boneset URLs, I seem to have accidentally misled some of the direction with my issue description. Sorry for the confusion. I've clarified in my comment on server.js.
Also, it seems like this branch may have been branched off of your other pull request instead of main—there are changes in data_extraction/ here, which seem like they're from that PR. Those shouldn't be committed into this branch. In general, whenever you make a branch, it should be branched off of whichever branch you want to make a pull request into. So since this branch has a pull request into main, this should have been branched off of main instead of any other branch. There are two ways to accomplish this:
- Option 1:
- Check out
main(git checkout main) - Update
main(git pullorgit pull origin main) - Branch from
main: (git checkout -b <new-branch-name>orgit branch <new-branch-name> && git checkout <new-branch-name>)
- Check out
- Option 2:
- On issue page on GitHub, go to "Development" in the sidebar and create a new branch from there
- Locally, fetch from remote (
git fetch) - Checkout newly created branch (
git checkout <branch-name>)
| *.pyc | ||
|
|
||
| # XML files | ||
| *.xml No newline at end of file |
There was a problem hiding this comment.
Why was this added?
There was a problem hiding this comment.
Why was this removed? This file still seems useful and as far as I'm aware has no bearing on the issue being resolved.
There was a problem hiding this comment.
Nothing in the __pycache__ folder should be committed.
There was a problem hiding this comment.
While I do appreciate the work on this, a test suite is not necessary at this time. At this stage it would slow us down, and I've set up work in other issues to set up tests. We can get rid of this test suite for now.
I realize that my wording of the issue descriptions probably made it sound like server unit tests were necessary, so I'm sorry for the lack of clarity on that.
There was a problem hiding this comment.
All of the bones will be stored in the DataPelvis/ folder in the database, so that does not need to vary for all of the endpoints here. While I do like the approach you took with having the endpoints take in an extra optional argument for the boneset, that is unnecessary. If an endpoint gets a sub-bone, for example, it will pull it from the same folder no matter which boneset the sub-bone is a member of.
What we're really looking for here is just a refactoring of the endpoints where the DEFAULT_BONESET_ID is being used. My IDE tells me there are two. And in those, it looks like they're trying to get all of the data from what is currently the only boneset available, by grabbing the data from that one JSON file. Therefore, in order to support adding more bonesets in the future, instead of grabbing only that one JSON file, they should loop through data in all of the JSON files in the boneset/ directory in the database. And the DEFAULT_BONESET_ID const would have to be refactored out and removed so that it is no longer hardcoded that it's the only boneset we have. Only the endpoints where the BONESET_JSON_URL const is being used would have to be refactored this way.
I'm sorry if the issue description wasn't clear–I understand how it may have caused confusion here. I've rewritten the issue description a bit to clarify what needs to be done.
Pull Request Summary
Closes #219
Refactorbony_pelvis for backward compatibility
Allows new bone sets to be easily added by following the GitHub directory structure convention without code changes.
PR Checklist