cache (3)

神木，我有病。居然一直在寫筆記，還搞到半夜。

anyway, 快放假了...?

搞這 cache 實在大傷腦筋啊，日前開會決議不要用掃的，
在每次有新留言時更新 count 即可。當下不覺得有什麼問題，
於是著手開始進行。不過現在又覺得好像不大對？這種事也發生過
好多次了，所以說才覺得其實當面討論會遺漏掉很多事啊 @@

因為現在是在有追加留言時重算 count,
但如果一直都沒有呢？假設三十天過去沒有任何留言，
那所有的 count 都應該歸零才是。

也就是說，假設現在有某個相片衝到 10000 留言，
然後七天之內都不要有任何新留言，那他就永遠停在第一名了。

只是這時如果忽然有一個人過來留言，那 count 又會降到 1,
當然也就變成倒數第二名了。（第一當然是 0 的）

也就是說，定期更新所有的 count 感覺還是必要的。
至少已經比 page view 好處理了，畢竟 comments 有紀錄，
而 page view 沒有... page view 要留紀錄的話，
豈非操死 database? 當然其他手段，例如先存 session
定期灌回、page cache, 等等又是另外一回事。

我是覺得定期掃沒啥啦... 大不了就掃最新的 5000 筆，
太老的上排行榜也沒意思啊，又不是在玩遊戲，讓老人可以獨霸排行？
更何況天梯（game ladder）也是會砍掉重練啊，這也很平常。



不過值得筆記的應該是中途試了非常多東西。
懶得再重寫一次了，參考：cross repository query path?
發現跨 mysql database 的速度實在是很慢，就算 DataMapper 支援，
大概也是不能用。所以就把 comments_count 裝回 :default repo,
命名為 cache_comments_count, 表示 cache 開頭的是不得不放在這，
其實也是可以 tuncate 掉的東西。

然後 controller 裡其實沒辦法用 Sync.comments_count(resource),
因為這是 DataMapper 的東西，上次測試在 rails 裡面跑問題一堆，
所以大概還是得避開 dm 的東西，只好重寫一份在 Cache::CommentsCount 裡面。

然後忽然想到，那是不是本來就應該寫在 model 上？
不過這是小問題，不值得特別拿出來講就是了。

總之就是測試暫時沒問題啦。雖然這看起來很怪：

Photo.repository(:cache) do
  Photo.for_public
end

會變成從 :cache 裡抽出 photo 但是判斷是用 :default 的 permission.
正好在同一個 database(schema) 下不會有問題就是了...?

相較之下 AR 真的很殘廢，有點 poor man's solution 的味道...
複雜一點的操作根本都要下海寫 SQL... 我也居然從完全不懂看到似懂非懂了...

*

page view 大概就暫緩吧