P.S meant to say that apart from preserving the API I see no issues with switching the cache backend, unless some one was using pickleshare directly to access it outside Leo, seems unlikely.
On July 16, 2017 12:29:56 PM CDT, vitalije <vitali...@gmail.com> wrote: >What I found is that there was a bug in sqlite-leo code which prevented > >refresh-from-disk to work quite reliably. Happily, I have found and >fixed >it. In sqlite-leo branch as from cbb8f876854b looking for a file in Leo > >cache is fully avoided. That brought small speed up in starting Leo. >Master >version of Leo opens LeoPyRef.leo with 100% cache hit on my machine in >1.27s and sqlite-leo opens same file but in db version, in 1.03s. This >speed gain is not a big deal, but now I can switch branches however I >want >and Leo responds correctly. No recovered/resurrected nodes, ... both >while >Leo is running and when it is first closed, branch switched and then >opened >again. > >Having said that, my earlier recommendation than one should avoid >switching >branches in same folder is not valid any more. > >I still don't know if leoCache was responsible for all those problems, >or >perhaps new-read solved some problems elsewhere that Edward had >noticed, >and problems that I have noticed were caused only by sqlite-leo bug. > >We shall see. If creating recovered nodes when switching branches is >still >happening in master branch, then most probably problems come from >cache. If >they don't appear anymore then most probably those problems were solved >in >new-read branch and now fix is merged in master. > >One way or the other, sqlite-leo doesn't use leoCacher anymore to look >for >files and as a result all problems with switching branches disappeared. > > >In the past, leoCache.py was a great addition, but I'm starting to >think >> it may be nearing the end of it's useful life. I am willing to >consider >> replacing it with sqlite code. >> > >If you agree I can write new version of Cacher that uses sqlite db as >backend and stores all cache values in one file. This can be convenient > >especially for debugging purposes. If ever cache is suspected to be >source >of problem, it would be easy to rename database file or just table >inside >database which would have same effect as deleting cache folder. >However, it >gives much more flexibility in querying which cache record is actually >problematic and extracting it for further investigation or use in unit >tests. > >Vitalije > >-- >You received this message because you are subscribed to the Google >Groups "leo-editor" group. >To unsubscribe from this group and stop receiving emails from it, send >an email to leo-editor+unsubscr...@googlegroups.com. >To post to this group, send email to leo-editor@googlegroups.com. >Visit this group at https://groups.google.com/group/leo-editor. >For more options, visit https://groups.google.com/d/optout. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
