Using different API endpoints for a "same" stream

[meltanolabs]

Using different API endpoints for a "same" stream

[laurentS]

Thanks for explaining where it comes from. From my perspective, just having the issues as child of repo instead of the current setup works fine, because it covers our use case 😅 I don't think there would be many cases where you specifically want "less data for your quota", but if that pops up someday, we can figure out something?

I can try and implement this, and follow a similar logic for other streams where a similar situation exists.

[aaronsteers]

@laurentS - Thanks for raising this! I wonder if it's best to just support issue_comments in this case as a child of repo, driven by the {repo}/issues/coments endpoint instead of being a child of issues (aka, a child of repo instead of a grandchild of repo). Performance would be improved, I think, to make a paginated repo-level call, rather than a separate round of calls for each issue, and it would also address your point about rate limits.

At the time when I was developing the first version of this tap, we were needing an example case to prove parent-child and grandparent-parent-child relationships for the SDK, and for this reason we probably chose a less-than-ideal retrieval path - in the interest of proving the more complex use case.

Given all the above, I think I'd be inclined to take your proposed logic in place of how we have it set now. Wdyt?

[Ry-DS]

Was this resolved in #9? We could close then if so 👀

[laurentS]

Indeed, thanks for pointing it out.