-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110794/#review33638
-----------------------------------------------------------


No. I do not think this is the correct way of going about this.

The main problem is that if some 10 files are failing, they will fail each time 
the FileIndexer will run. We do not want to try and reindex those files on 
startup each time. Also, what's the point of showing this to the user? They 
cannot do anything about it. It will just annoy them.

Instead, I think it would be better to modify the kext:indexingLevel to -1 or 
some other value. This way, those files will not be returned in the fillQueue 
query. Maybe in 4.12 we could have some code which tries to re-index all the 
files which have not been successfully indexed.

- Vishesh Handa


On June 3, 2013, 3:57 a.m., Simeon Bird wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/110794/
> -----------------------------------------------------------
> 
> (Updated June 3, 2013, 3:57 a.m.)
> 
> 
> Review request for Nepomuk, Jörg Ehrichs and Vishesh Handa.
> 
> 
> Description
> -------
> 
> FileIndexer: report if indexing certain files failed
> 
> At the moment, if the fileindeer chokes on a file, it will be repeatedly
> requeued, and the indexer will consume all the CPU forever.
> 
> This patch stores a list of any files that did not index internally and
> does not add them to the queue. This list does not persist across
> restarts, because indexing failures may well be transient.
> 
> We are limited to 100 failed files. Once we have this many, just stop
> indexing.
> 
> Furthermore add dbus methods to the indexer service to report the
> number of failed files as well as their filenames and error message.
> 
> BUG: 315817
> FIXED-IN: 4.11
> 
> There should be some sort of ui component for this, so that user can easily 
> see and 
> copy-paste the names of files that didn't index properly. I didn't write this 
> yet, 
> as I was hoping that by waiting I can just add it to the new qml controller.
> 
> I'm not completely convinced by the showFailedFiles function either - a 
> newline
> separated list seems like it could be improved upon.
> 
> 
> This addresses bug 315817.
>     http://bugs.kde.org/show_bug.cgi?id=315817
> 
> 
> Diffs
> -----
> 
>   interfaces/org.kde.nepomuk.FileIndexer.xml 
> 9e56cb139f05e4a4267adf575d0894c5a69935a1 
>   services/fileindexer/fileindexer.h 3d87a04bcf6a7d8c9402e8085daeb7c630bc4e91 
>   services/fileindexer/fileindexer.cpp 
> 8c712dfc43af06c55f5503295e8460da89e5fcb5 
>   services/fileindexer/fileindexingqueue.h 
> b017f226b0a209d57bcac7b9fb949d5b17e79cba 
>   services/fileindexer/fileindexingqueue.cpp 
> 2b119255e39fc873db08148291e1638e1a8c510a 
>   services/fileindexer/indexscheduler.h 
> c6a9e35bed7ce885a8948aec37eccd5d23f7eb5d 
>   services/fileindexer/indexscheduler.cpp 
> 2835eb21274c80738b47f4526c47028d0d9dd06e 
> 
> Diff: http://git.reviewboard.kde.org/r/110794/diff/
> 
> 
> Testing
> -------
> 
> Compiled, ran, called the dbus methods. No files fail to index for me now 
> though
> 
> 
> Thanks,
> 
> Simeon Bird
> 
>

_______________________________________________
Nepomuk mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/nepomuk

Reply via email to