[ditrack commit] r2407 - src/trunk/DITrack/DB
Vlad Skvortsov
vss at 73rus.com
Tue May 20 19:25:45 PDT 2008
Oleg Sharov wrote:
[skipped]
>>>> Looking at the following block of code makes me thinking: should we
>>>> place all caching logic under Issue.load()? With the current
>>>> approach we have to be very careful to keep the cache coherent
>>>> (e.g. whenever the issue is loaded, we have to update the cache).
>>>>
>>>>
>>> Issue.load() can't be used to work with cache, because class Issue
>>> is used for WC & LMA.
>>
>> Yes, but the issue only gets load()ed from WC. Why exactly couldn't
>> that work?
>>
>
> If we move work with cache to DB.Issue.load() we get cache files of
> each issues. Now we have one shelve for all issues. Besides, I'm
> thinking may be we must make DB.Issue more abstractive, and move
> logics of work with disk to DB.WC.
So why don't we implement the following:
* WC.__get_item__() to transparently check if the issue is in the cache
(and is valid) and if it's not, then load the issue and update the cache.
* WC.issues() to go over the directory list (as in the 'else' block
starting at line 283) and use __get_item__() to load issues
(automatically going through the cache). No special logic (currently in
the 'while' block starting at line 274) will be then needed to check for
new issues.
m?
--
Vlad Skvortsov, vss at 73rus.com, http://vss.73rus.com
More information about the Dev
mailing list