HomePhabricator

Fix TopicHistoryStorage, which is used when no cache applies

Authored by matthiasmullie.

Description

Fix TopicHistoryStorage, which is used when no cache applies

We fall back to database (instead of cache) in 2 cases:

  • index applies but some data is missing, in which case it's fetched by backingStoreFindMulti
  • no index applies (e.g. out of range - only first x entries are cached) in which case it's fetched from storage::findMulti

Which means that findMulti can be called directly, with the exact
same $queries we send to cache indices (TopicHistoryIndex)
TopicHistoryIndex was doing some manipulations: it would expect a bogus
primary key "topic_root_id" and figure out the real queries from there.
However, the storage counterpart was never properly addressed.
I've moved the resolution code to TopicHistoryStorage, which can now
also deal with "topic_root_id". The original code in TopicHistoryIndex
has been replaced with a simple call to the code that's now been moved.

Bug: T91916
Change-Id: Icce032b04817d75ec322c24ce1e6b611c8d1c1ca

Details

Committed
matthiasmullieMay 12 2015, 2:09 PM
Parents
rEFLW84ad8ca16cd7: Merge "Allow editor re-initialization"
Branches
Unknown
Tags
Unknown
References
refs/changes/54/210354/1
ChangeId
Icce032b04817d75ec322c24ce1e6b611c8d1c1ca