[Kde-pim] Favourites and Advanced Folders Links wrong after deleting akonadi db

[Martin Steigerwald]

Am Sonntag, 17. Februar 2013 schrieb Sven Burmeister:
> > > Back then I suggested to not rely on "unique" numbers, i.e.
> > > 1,2,3,4... within  the akonadi db but create real unique numbers or
> > > at least save a unique number in the config and db and check whether
> > > they match when starting akonadi. this would allow to prevent this
> > > kind of trouble and even
> > > data loss, e.g. because messages are moved to some folder, e.g. the
> > > trash.
[…]
> > > But this was not seen as reasonable and thus the issue still exists.
[…]
> > I agree with you. I remember the original problem and the fix did not
> > really fix it, just moved the issue to a different area.
[…]
> > Its accepted knowledge and mentioned on the wiki that the akonadi db is
> > just a cache and deleting it will not harm your email data. This is
> > simply not true and needs to be stated clearly. Deleting the akonadi
> > cache can severely mess up your email data if you have filtering rules
> > setup.
> 
> Yes. I argued for quite a while but the person in charge did not see
> these  issues as valid because akonadi does use unique IDs according to
> his understanding. The fact that it obviously fails when used in
> reality, which it would not do with real unique IDs, did not
> convince/bother him.
> 
> Hence at some point I just acknowledged that he does not want to
> understand  why his definition of unique is not unique outside the db
> and thus causes trouble. In fact it's not even unique within the whole
> akonadi framework which includes configs etc. IMHO the whole logic of
> using 1,2,3,4 as unique numbers is far too fragile and thus designed to
> fail.
> 
> But since he put a lot of effort into not wanting to understand the issue
> and  arguing against it, the fix must be really complicated and thus
> avoided. Apparently it is not as simple as creating a real unique number
> and storing it in the config/agents and the db in order to compare them
> while akonadi starts- up.

Hmmm, I think its important to fix it. I darkly remember that discussion,
I think.

Deleting an Akonadi database happens also when switching backend for example 
from PostgreSQL back to MySQL or vice versa.

If Akonadi is a metadata cache, I think, there should be no data loss except 
for metadata. At least I think its good if KMail detects when filter rules 
point to non existing (cause new id) folders.

And possibly have the name or a hash of a name of a folder as a fallback, if 
the Akonadi id does not match anymore.

The other thing would be: Moving filter rules and favorites into Akonadi 
database. Then at leasts its all empty when one deletes the Akonadi 
database. And could be exported and imported with some tool that just makes 
a database dump.

The references from KMail filter and favorites from its configuration file 
to the Akonadi database are asking for trouble especially when just using 1, 
2, 3, 4 as numbers. So either keep it all in one self contained place – the 
Akonadi database – or make references as stable as possible.

But since I do not do the coding… its not my decision anyway. This is just 
what I think would be sane.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/