アカウントに関連したデータ構造の見直し

[turtton]

• Accountクラス内にConfidentialクラスを追加
  アカウントのパスワードなどのセンシティブな情報を格納するクラスになります
• Accountクラス内にis_botフラグを追加
• Followクラス内に以前話していたULIDを追加
• AccountDataクラス内にMetaDataクラスを追加
  これはMastodonやMisskeyにもある機能で、各種リンクとかを載せるためのデータになります。
  
  ActivityPubデータ内のattachmentに相当します

Signed-off-by: turtton top.gear7509@turtton.net

[github-actions]

PR Preview Action v1.2.0
Preview removed because the pull request was closed.
2023-02-13 00:00 UTC

[turtton]

プレビューに使えるかなとワークフローをいじいじしてたんですが、どうやらmermaidは見えなかったり、全てのボタンのリンクがこのプレビューサイトにならなかったりと結構微妙な感じになっちゃいましたね。これだったらCloudflare pages使った方がよかったな

[turtton]

今はこんな感じです

[turtton]

discordの話を受けてis_botフラグを追加しました

[turtton]

そういやこれってメアドとかパスワードみたいなデータはどこで持つんですか？それもアカウントに入れるべきですかね？

[HalsekiRaika]

アカウントのPKを使って別のテーブルで持つべきかな
メアドとかのユーザーの情報は機密に当たるから暗号化したものを特別で持つべきだと思う

[turtton]

こんな感じでしょうか

[turtton]

書いてから思ったんですが、アプリケーション側のデータ構造としてもAccountクラスとは完全に分離すべきですかね

[HalsekiRaika]

結合した時点で漏れるリスクってのはどうしても出てくるから完全に切り離したほうが安全かも

[turtton]

切り離しました。これで大丈夫そうでしょうか

[HalsekiRaika]

OK 👍

[turtton]

一応確認なんですが、MetaDataの順番を表現するためにIndexフィールドを設定したんですけど、これってVectorの順序で表現すべきですかね。
DB側ではindex的なものを持たせるとした場合、そこでフィールドとカラムの内容の乖離が埋まれる方がダメですかね

[HalsekiRaika]

PKにAuto Incrementを使用すれば順番は担保されるはずだからそこまで考えることはないはず
最悪アプリケーション側でソートする

[turtton]

PKで順序守れそうならこのフィールド消しますね

[turtton]

大丈夫そうだったらマージしちゃってください

[turtton]

あれ、でもこの場合だとPKの情報をアプリケーション側が持ててないので内容の更新が出来ませんね。固有のIDは持っておくべきですね

[HalsekiRaika]

そうだね
APIの返却値としてOrderedなリストを返却するようにすれば一応Indexは剥がせるけどそれができない言語もあるから

{
  "meta": [
    1: { .. }
    2: { .. }
    3: { .. }
  ]
}

って構造体でやり取りするようになるかも

[turtton]

APIの返却値としてOrderedなリストを返却するようにすれば一応Indexは剥がせるけどそれができない言語もあるから...

それはWebAPIの定義をやるときに忘れないようにしておきますね。

とりあえずMetaDataクラス内にPK用のidを入れました。Vectorの配列で順序の表現をするってところは変わってない認識で大丈夫ですよね？

[turtton]

大丈夫そうなのでマージしまーす