Project

General

Profile

Actions

最適化 #621

closed

listの復元処理の最適化

Added by Osamu Koga almost 11 years ago. Updated almost 11 years ago.

Status:
終了
Priority:
通常
Assignee:
Target version:
Start date:
2013-10-20
Due date:
% Done:

0%

プラグイン名:
list

Description

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

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

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

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


Files

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
Actions #1

Updated by toshi_a 初音 almost 11 years ago

  • Status changed from パッチ適用待ち to レビュー待ち
  • Assignee set to Osamu Koga

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

Actions #2

Updated by Osamu Koga almost 11 years ago

  • Status changed from レビュー待ち to 解決

確認しました。

Actions #3

Updated by toshi_a 初音 almost 11 years ago

  • Status changed from 解決 to 終了
Actions

Also available in: Atom PDF