Bug 335183

Summary: Akonadi update from 4.12 to 4.13 fails
Product: [Frameworks and Libraries] Akonadi Reporter: Tomáš Chvátal <tomas.chvatal>
Component: serverAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: dvratil
Priority: NOR    
Version: 1.12.0   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In: 1.13.0

Description Tomáš Chvátal 2014-05-22 11:04:48 UTC
I encountered multiple issues while migrating my setup as follows:

1) My tables were created by akonadi in myisam format so I had to convert them by hand, maybe update script ought to do itself. This was not problem before as there were not so strict foreign keys.

2) When updating I had some collisions which resulted in things like:

"ALTER TABLE PartTable ADD FOREIGN KEY (pimItemId) REFERENCES PimItemTable(id) ON UPDATE CASCADE ON DELETE CASCADE" 
Updating index failed:  

Which was then easily fixed by mysql command to clear the clashes:
DELETE FROM PartTable WHERE pimItemId NOT IN (SELECT id FROM PimItemTable);

This happened multiple times so it might be good idea to run this call prior the alter...
MariaDB [akonadidb]> DELETE FROM PimItemTable WHERE collectionId NOT IN (SELECT id FROM CollectionTable);
Query OK, 2 rows affected (0.11 sec)
MariaDB [akonadidb]> DELETE FROM PartTable WHERE pimItemId NOT IN (SELECT id FROM PimItemTable);
Query OK, 3 rows affected (0.61 sec)
MariaDB [akonadidb]> DELETE FROM CollectionAttributeTable WHERE collectionId NOT IN (SELECT id FROM CollectionTable);
Query OK, 34 rows affected (0.01 sec)

After I ran all of the above my akonadi is again working as expected.


Reproducible: Always
Comment 1 Daniel Vrátil 2014-05-28 09:25:59 UTC
We've seen this a lot during 1.1x -> 1.12 migration, so we will probably have to add those. I wanted to avoid deleting any data behind user's back, on the other hand these are already unreachable, so it should not lead to any data loss...