Bug 335183 - Akonadi update from 4.12 to 4.13 fails
Summary: Akonadi update from 4.12 to 4.13 fails
Status: RESOLVED FIXED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: server (show other bugs)
Version: 1.12.0
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-22 11:04 UTC by Tomáš Chvátal
Modified: 2014-07-09 20:21 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 1.13.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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...