プロジェクト

全般

プロフィール

最適化 #621

完了

listの復元処理の最適化

Osamu Koga さんが10年以上前に追加. 10年以上前に更新.

ステータス:
終了
優先度:
通常
担当者:
対象バージョン:
開始日:
2013-10-20
期日:
進捗率:

0%

プラグイン名:
list

説明

全体の挙動としてバグっているわけではないのですが、起動時にエラーが出ていて、コードを追っていたら気づいたので。

起動時にリストを復元する際、前回開いていたリストIDを元にして復元処理をしていますが、この処理がバグっています。
Hash の要素の存在判定に defined? を使っていますが、Rubyではこのやり方はうまく行きません。
代わりに Hash#has_key? を使う必要があります。
添付のlist.patchがこの修正です。

ただし、そもそもこれらの処理がなくても、各 Service に対して fetch_list_of_service を呼び出しているため、
リストの復元自体は正常に行えています。
(全体としてバグっていない理由がこれです)
したがって、問題の箇所と、この用途でしか使われていない visible_list_obj はまるごと削除してしまっても問題ないのではないかと思います。
添付のlist_remove_obj.patchがこの方針での修正です。

どちらのパッチもdevelopブランチで作成しましたが、masterブランチにも問題なく適用できるようです。


ファイル

list.patch (924 Bytes) list.patch Osamu Koga, 2013-10-20 23:50
list_remove_obj.patch (1.78 KB) list_remove_obj.patch Osamu Koga, 2013-10-20 23:50

toshi_a 初音 さんが10年以上前に更新

  • ステータスパッチ適用待ち から レビュー待ち に変更
  • 担当者Osamu Koga にセット

これはAPIキャッシュではキャッシュの生存時間を指定できないようにして、ごく一部キャッシュを長く残したい処理では個別に対応するというポリシーに従って書かれていたコードです。
リストはツイートを取得する以外は非常にAPIレートリミットが厳しいエンドポイントで、こういった工夫は重要と考えていましたが、昨今はキャッシュが強いために「mikutter外で作成したリストをmikutterで使う方法は」「なかなかリストに入れたユーザが同期されない」といった質問が増えており、このようなキャッシュ戦略自体を見なおす必要があると考えていました。
したがって、やや強引では有りますが、こういったキャッシュのロジック自体を消すという対応を受け入れます。動作しないようになっていたとのことですが。

Osamu Koga さんが10年以上前に更新

  • ステータスレビュー待ち から 解決 に変更

確認しました。

toshi_a 初音 さんが10年以上前に更新

  • ステータス解決 から 終了 に変更

他の形式にエクスポート: Atom PDF