Optimize query for unscanned files - #364
Conversation
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
Signed-off-by: Patrick Fischer <mail@patrickfischer.ch>
Signed-off-by: Patrick Fischer <mail@patrickfischer.ch>
Signed-off-by: Patrick <zero0cool0@users.noreply.github.com>
df5409b to
1cb0f89
Compare
If my interpretation of the code in
BackgroundScanneris correct,getNodeForFile()relies on the existence of an existing mount to determine theNodefor a givenfileId.Sometimes, this fails. Specifically, this line is returning an empty array.
$cachedMounts = $this->userMountCache->getMountsForFileId($fileId)Tracking this further, I found that no corresponding mount can be found for some
fileIdthat are present inoc_filecachewhen joiningoc_mountsthroughoc_storage.Why is this even a problem, other than creating many log entries?
If the number of such entries in
oc_filecacheis large then the entire batch contains non-scannable entries, starving the scanning of other entries inoc_filecachethat have a corresponding mount.My PR proposes to only process files whose
fileIdthat can be related to an existing mount.More details:
I have a lot of entries in
oc_filecachethat look like this:These entries correctly relate to an entry in
oc_storages:However, no mount can be found: