From kde-pim  Mon Feb 18 18:15:55 2013
From: Sven Burmeister <sven.burmeister () gmx ! net>
Date: Mon, 18 Feb 2013 18:15:55 +0000
To: kde-pim
Subject: Re: [Kde-pim] Favourites and Advanced Folders Links wrong	after deleting akonadi db
Message-Id: <50439712.rrVx9Bb5lN () linux-ly0d>
X-MARC-Message: https://marc.info/?l=kde-pim&m=136121138232246

Am Sonntag, 17. Februar 2013, 23:37:16 schrieb Andras Mantia:
> Sven Burmeister wrote:
> > Yes. This was reported already but not seen as valid. You simply must not
> > delete your db without deleting everything else.
> 
> Or without fixing the config files. :)
> 
> > 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.
> 
> I might have missed (or forgot) the discussion. The solution would be to
> identify the folders based on remoteId. But remoteId is unique only inside a
> certain folder, so the code will be somewhat more complex (you would
> basically need to store a full path of remoteId's). It is doable, but the
> problem is as always: somebody needs to code it, including with upgrade
> scripts for existing configuration files.

That's not the easiest fix/solution. Of course it would be nice if everything 
falls into place, even if one removes a corrupted database etc. but the fix to 
prevent filters etc. being assigned to random folders without the user 
noticing it but by some "lost" emails is a lot simpler.

When an akonadi database is created it should include one unique ID. This can 
even be added to already existing set-ups. The ID enables each application 
that uses akonadi to get that ID from the akonadi DB the first time it 
accesses it and store it in the app's config.

If the akonadi DB is removed it will be re-created with a different ID. Apps 
using akonadi can check whether the DB's unique ID matches the ID they have 
stored. Like a token.

If the IDs do not match the app notifies the user that all references to 
akonadi might be screwed-up. Now the user knows and can check the folders etc. 
The next improvement would be to offer to go offline in order to prevent 
filters kicking in before the user has the chance to sort them out.

As already mentioned there are of course better solutions to the issue, e.g. 
removing all resources that are not truly unique by the app or even using real 
unique IDs and thus being able to fix the the references without any user 
interaction. But the first step would be to make it possible to identify the 
akonadi DB by a real unique ID.

Sven
_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/