今天我們繼續分析 Kafka 的 PR 情況，但是我單單跟 github 的 rate limit 就搏鬥的一個小時
並且用到了不少 DuckDB 1.1.0 後面才有的功能

CREATE SECRET github (
    TYPE HTTP,
    EXTRA_HTTP_HEADERS MAP {
        'Authorization': 'Bearer <github_pat_ 開頭的 github token>'
    }
); 

一樣的我們先得到 kafka 近期 100 隻 PR 的情況

CREATE TABLE kafka AS 
FROM read_json_auto("https://api.github.com/repos/apache/kafka/pulls?state=closed&sort=updated&direction=desc&per_page=100");

重點來了， github 的 comments 是在不同的 api
而且 comments 還分成兩種，一種是 review (有對應到 code) 一種是正常的 comments

CREATE TABLE kafka_comments AS
SELECT number, _links.comments.href as comments , _links.review_comments.href as review_comments
FROM kafka;

所以我們要先拿到 200 隻 api 的 endpoint(這邊偷懶，各拿 80 隻就好)。

SET VARIABLE normal_comments = (SELECT  List("comments")  FROM kafka_comments LIMIT 80);

SET VARIABLE review_comments = (SELECT  List("review_comments")  FROM kafka_comments LIMIT 80);

打這 160 隻 api 的 endpoint。

CREATE TABLE nc AS
SELECT * FROM read_json_auto(getvariable('normal_comments') , union_by_name = true );

CREATE TABLE rc AS
SELECT * FROM read_json_auto(getvariable('review_comments') , union_by_name = true );



不過今天搏鬥失敗，明天在繼續 🥲