This checks if the filename exists, and if not, removes the entry from the database.
This would be a fix to https://bugs.kde.org/show_bug.cgi?id=398260
leinir |
This checks if the filename exists, and if not, removes the entry from the database.
This would be a fix to https://bugs.kde.org/show_bug.cgi?id=398260
Lint Skipped |
Unit Tests Skipped |
The reason i didn't do this before is that it does file system access, which is precisely what the cache is supposed to try to avoid... You've got a large collection, right? What sort of impact does this have on load time? (baloo shouldn't matter in this case, but it's good to test with that turned off anyway...)
Well, the thing is, I have a large collection(sqlitebrowser counts about 586 entries right now), yes, but I also have a fairly beefy computer. Starting peruse with clear-db takes way longer than this(which is near instantaneous), but because I have a beefy computer I suspect it might be the debug messages that is the major cause of the slowdown with clear-db. Either someone with a slow harddrive should check this, or I'll drop the patch and wait for one that is theoretically speedier.
One way to check for speed of this sort of stuff is to stick things on an SD card and point Peruse at that... those things are dog slow, handy for testing what's actually heavy :) (because yeah, i've got an SSD in this machine, which is similarly useless for testing IO impact...)
hm... will have to chase down an sd card reader first :D
(Or someone should check on windows...)
This changes to QFileInfo::exists(filename), because the docs say that is a little faster.
Also put it under removebook where it makes most sense.