[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