[stable34] fix(metadata): bind chunked file ids in dropMetadataForFiles - #64092
provokateurin merged 1 commit into
Conversation
Signed-off-by: dispather <62810211+dispather@users.noreply.github.com>
|
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.) |
|
Thanks for your first pull request and welcome to the community! Feel free to keep them coming! If you are looking for issues to tackle then have a look at this selection: https://github.com/nextcloud/server/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22 |
Manual backport of #62331 to
stable34.MetadataRequestService::dropMetadataForFiles()splits$fileIdsinto chunks of 1000 and iterates over them, but theINclause still binds the full$fileIdsarray instead of the current$chunk. Each iteration therefore issues the same full-sizeDELETE, which produces theMore than 1000 expressions in a list are not allowed on Oracle.entry fromQueryBuilder::prepareForExecute()and repeats an identical statement once per chunk.The sibling method
IndexRequestService::dropIndexForFiles()carried the same copy/paste bug and was already backported tostable34in #62771. This applies the equivalent one-line fix to the metadata table.Difference from the master patch
master's #62331 switches the chunk size to
IQueryBuilder::MAX_IN_PARAMETERS, which does not exist onstable34. This PR keeps the existing literal1000and changes only the bound variable, matching the shape of the already-mergedstable34backport #62771 (+1/-1, same file family).getMetadataFromFileIds()a few lines above also binds an unchunked$fileIds, but master's #62331 leaves it untouched as well, so it is out of scope here.Why this is filed by hand
/backport to stable34was requested on #62331 twice without response — in prose on 2026-08-08 and as the bot command on 2026-09-06. Both requesters haveauthor_association: NONE, so the command does not appear to be honoured from non-members. Filing manually rather than leavingstable34unpatched; happy to close this if backportbot is triggered by a maintainer instead.Refs #62331, #62771, #62325