Hello! On Arch fully updated I get some problems with akonadi: (akonadi 15.08.1-1, kmail 15.08.1-1) The akonadi errors I always get (database driver Mysql): DATABASE ERROR: Error code: 1452 DB error: "Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`collectionpimitemrelation`, CONSTRAINT `collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)" Error text: "Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`collectionpimitemrelation`, CONSTRAINT `collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) QMYSQL3: Der Befehl konnte nicht ausgef\u00FChrt werden" Query: "INSERT INTO CollectionPimItemRelation (Collection_id, PimItem_id) VALUES (:0, :1)" This error also came up after completely rebuilding all mail accounts in akonadi. Also the "search mail" function to create virtual search folders seems not to work at all. It sometimes works one time but then always uses the same search pattern everytime no matter what search criteria I enter in subsequent searches. For some really obvious patterns like "somewhere in the mail header" "contains" "gmail.com" I do not get any search results at all though searching "all folders"... BTW this behaviour is the same when I switch to an external Mariadb server. Now I do not know if these two issues are related but I assume so. Also the akonadi control module shows only one (!) single gmail resource though akonadi console shows about 10 mail resources, also calendar and contact resources and so forth. On a fresh user account I run into the same problems.... Is there a way to clean up this situation without reconfiguring the complete akonadi setup (including all mail accounts)? In the past I had about a dozen virtual virtual search folders running well within kmail. Now I am lost here. Reproducible: Always Steps to Reproduce: 1. search for "gmail" in all mail folders 2. if results come up, close search, search again for a different search pattern 3. Actual Results: either there are no search results at all or there are the same results no matter which search pattern everytime ... Expected Results: search should work I consider a mail client without working search completely useless, why not use a web browser for checking mail? - cause you want to manage mail, search it, filter it, archive it.... nothing of these works without working search... working virtual folders based on searches are standard now, do not work without search, obviously...
Is this still an issue in KMail 5.1.1? I had a similar problem, but it seems to be fixed now. Also, possible duplicate of https://bugs.kde.org/show_bug.cgi?id=352472.
On the latest KDE 16.08 on Arch search still cannot be refined after creating a search folder. The virtual folders' context menu shows the entry "edit search" but this does not seem to work. If I add additional search criteria or remove some (which doesn't work at first because the "remove" buttons are greyed out - you have to add one criteria first then it's possible to delete...) - the results do not change at all. this doesn't work since kmail2 has been published - please remove the option from the context menu if it will not be fixed. Otherwise it just leads to a frustrating user experience. thx for reading, p.
Git commit d54d1f241f1a421330efbf2f71efe4d1acd18f04 by Daniel Vrátil. Committed on 08/01/2017 at 15:41. Pushed by dvratil into branch 'Applications/16.12'. Search: match all results against DB first to exclude invalid results In some cases the search backend can return results that actually no longer exist in Akonadi DB (for example because the indexer is busy indexing something else while an Item was removed, which triggered search update), or because it went out-of-sync with the DB due to a bug or manual cleanup. This lead to a lots of (albeit harmless) foreign key constraint errors as we tried to insert items into CollectionPimItemRelation table which did not exist in PimItemTable. To prevent this we first match the results against PimItemTable to get only the existing Items (we need them anyway for change ntf) and then insert only those into the CollectionPimItemRelation table. This does not fix problems with search updates unfortunately. M +32 -13 src/server/search/searchmanager.cpp https://commits.kde.org/akonadi/d54d1f241f1a421330efbf2f71efe4d1acd18f04
*** This bug has been confirmed by popular vote. ***
Sorry for being late. Ideally, a bug should of course be marked as duplicate before it is confirmed by popular vote. *** This bug has been marked as a duplicate of bug 277007 ***