https://bugs.kde.org/show_bug.cgi?id=451620
--- Comment #4 from Erik Quaeghebeur <bugs.kde....@e3q.eu> --- (In reply to Christophe Marin from comment #3) > (In reply to Erik Quaeghebeur from comment #2) > > This is still an issue in latest KDE 5 versions. (I again had to apply my > > manual SQL fix.) > > If you mean akonadi < 24.02, it won't get the fix. This branch is closed, > you need to backport the change manually. Ah, nice, it seems the great commit https://invent.kde.org/pim/akonadi/-/commit/fcc37ce297df718430f83f7feb669573c9b135f2?page=3#995e689d409482037d49b6b0893848ff42e9f64f likely fixed the issue. (The function is now at https://invent.kde.org/pim/akonadi/-/blob/master/src/server/storagejanitor.cpp#L301.) AFAIU, It does seem though that the fix still passes through a C++ data structure and uses a two-step approach. Namely, first a list of orphans is queried, it is copied to a QList (https://invent.kde.org/pim/akonadi/-/blob/master/src/server/storagejanitor.cpp#L325), which is fed back into a second query that sets the orphaned items' collectionId to the lost+found one. This might be done more efficiently by directly selecting anything that qualifies as an orphan item using SQL directly in the WHERE of the UPDATE statement (cf. https://www.sqlite.org/lang_update.html, like in the DELETE statement in my Comment #1). -- You are receiving this mail because: You are watching all bug changes.
