最適化 #621
完了listの復元処理の最適化
0%
説明
全体の挙動としてバグっているわけではないのですが、起動時にエラーが出ていて、コードを追っていたら気づいたので。
起動時にリストを復元する際、前回開いていたリストIDを元にして復元処理をしていますが、この処理がバグっています。Hash
の要素の存在判定に defined?
を使っていますが、Rubyではこのやり方はうまく行きません。
代わりに Hash#has_key?
を使う必要があります。
添付のlist.patchがこの修正です。
ただし、そもそもこれらの処理がなくても、各 Service
に対して fetch_list_of_service
を呼び出しているため、
リストの復元自体は正常に行えています。
(全体としてバグっていない理由がこれです)
したがって、問題の箇所と、この用途でしか使われていない visible_list_obj
はまるごと削除してしまっても問題ないのではないかと思います。
添付のlist_remove_obj.patchがこの方針での修正です。
どちらのパッチもdevelopブランチで作成しましたが、masterブランチにも問題なく適用できるようです。
ファイル
toshi_a 初音 さんが約11年前に更新
- ステータス を パッチ適用待ち から レビュー待ち に変更
- 担当者 を Osamu Koga にセット
これはAPIキャッシュではキャッシュの生存時間を指定できないようにして、ごく一部キャッシュを長く残したい処理では個別に対応するというポリシーに従って書かれていたコードです。
リストはツイートを取得する以外は非常にAPIレートリミットが厳しいエンドポイントで、こういった工夫は重要と考えていましたが、昨今はキャッシュが強いために「mikutter外で作成したリストをmikutterで使う方法は」「なかなかリストに入れたユーザが同期されない」といった質問が増えており、このようなキャッシュ戦略自体を見なおす必要があると考えていました。
したがって、やや強引では有りますが、こういったキャッシュのロジック自体を消すという対応を受け入れます。動作しないようになっていたとのことですが。