generate-types: すべてのレスポンスを型生成してからマージする

[book000]

以下の処理を1日1回行う。実行時に既存プロセスがある場合はキルする

1. なければ、types テーブルと type_mapping をつくる
2. type-mapping を responses に突合して、typesにないレコードを抽出する。このとき、response_type は JSON に絞る
3. 順次、型生成し、types テーブルと type_mapping にINSERTする。responses と types の関係は多対一とし、関係性は type_mapping で定義する。生成した型結果が同じ場合は types 内で重複させない

※2と3をストリーミングでメモリ最低限に走らせられないかな？

型のマージ処理はいままでと同様。ただし、ソースが types テーブルとなる。

[book000]

responses テーブルの定義

https://github.com/book000/twitterts/blob/fa17a1d1fc55d19e90f81857ab1560fb22c48f3c/src/saving-responses/index.ts#L144-L165

[book000]

テーブル設計

types

• id: types テーブル内の PK、AUTO INCREMENT
• endpoint_type
• method
• endpoint
• url
• url_hash
• status_code
• generated_types: 生成された型データ
• generated_types_hash: 生成された型データのハッシュ値

ユニークキーは endpoint_type, method, endpoint, url_hash, status_code, generated_types_hash。

type_mapping

• response_id: responses テーブルの該当レコード ID。CHAR(36)
• type_id: types テーブルの該当レコード ID

response_id と type_id で複合 PK とする。

[book000]

パーティション分割をどう考えるかだな…。responsesテーブルはcreated_atでパーティション分割していて、古いものは定期的に削除される。 これに付随する形でtypesとかtype_mappingも消えるべきなんだけど、それをするためにはリレーションシップを張るかtypes側にもcreated_atを持たなきゃならん

[book000]

各レスポンスを受けたときにresponsesテーブルに型定義を随時生成して書き込む場合:

• generated_types_hashでuniqueとって、とった結果でページネーションという手間がある（難解かつ非効率なSQL）

[book000]

外部キーを設定して、ON DELETE CASCADEをつけるのがよさそう。そうします

[book000]

typeじゃなくてschemaとする。複数形はschemata