You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When listing tags, we call the GitHub API to fetch the list of git refs, and then iterate over them to get the git tag information (message, creation date, revision it points to) for each one. Each requires an addition GitHub API call. Essentially, this is a classic N+1 problem.
This will become very slow quite fast once we have more than a handful of tags for a dataset.
Directions to solve:
Maybe there is an API endpoint I am missing that could be used for this instead of what I have used. I didn't find any but perhaps there is a way.
Lazy-load some of the information not on initial fetch but on subsequent data access. This can speed up some use cases but will not help with others.
???
Note that this doesn't even include an additional API call that might be needed for some use cases, to fetch the data package itself beyond the revision the tag points to.
But on some repositories I noticed objects pointed to by refs/tags/ are notTag objects but Commit objects. That is very odd, perhaps related to how tags work in Git and maybe a difference between annotated and lightweight tags? I need to test to see if this works on tags created via the API. If this inconsistency cannot be explained I don't know if the API is used correctly. Will continue to investigate.
I started implementing this in feature/tag-listing-using-graphql. I am pausing for now as I have higher priority tasks.
I reached a point where I need to somehow plugin the GitHub API authentication token into the GraphQL API, and am not sure how to do that. Will continue investigating once time allows.
When listing tags, we call the GitHub API to fetch the list of git refs, and then iterate over them to get the git tag information (message, creation date, revision it points to) for each one. Each requires an addition GitHub API call. Essentially, this is a classic N+1 problem.
This will become very slow quite fast once we have more than a handful of tags for a dataset.
Directions to solve:
Note that this doesn't even include an additional API call that might be needed for some use cases, to fetch the data package itself beyond the revision the tag points to.
Github API
There are 3 ways to get tags ...
Git Data API "References"
GET /repos/:owner/:repo/git/matching-refs/tags
GET /repos/:owner/:repo/git/tags/:tag_sha
https://developer.github.com/v3/repos/#list-tags
The text was updated successfully, but these errors were encountered: