[Kde-pim] Data loss: kmail2 must not use existing [Folder-xy] settings on random new folders

[Kevin Krammer]

On Monday, 2011-12-12, Sven Burmeister wrote:
> Am Montag, 12. Dezember 2011, 23:03:48 schrieb Kevin Krammer:
> > > What if the database gets
> > > corrupted/removed on purpose and the new one starts again at 1?
> > 
> > Then you can have 99 new unique folders.
> 
> How if the chance of 1 being re-used is 100%? IMHO there is no uniqueness,
> only "low chance of having the same string twice".

That would be a bug in the database, it is required to issue unique non-
repeating 64bit numbers.

> 1-99 is not unique outside akonadi.

True, the Akonadi entity identifiers are of course only unique for one Akonadi 
system.
Akonadi clients only work with one server, so they can refer to the same 
entity (item or collection) by id.

> So either it must be replaced within akonadi or never be
> used outside.

Right.

> > causing problems in corner cases
> > where two distinct data sources get out of sync.
> 
> I do not agree that removing and adding resources is a corner case.

Neither do I.
Removing collections should not make their ids available again.

Looks like there is a bug in either the SQL statements that Akonadiserver uses 
to create its tables or in the database.

> Removing akonadis database either. In fact, it was advertised more than
> once that akonadi's db is just a cache and removing it does not lose any
> data. Well, now it does.

>From what I read so far it did not.

> I hope this does not mean that fixing this is regarded as low priority. It
> causes data loss and thus IMHO should have had highest priority.

I'd say finding out why removing a resource causes collection ids to become 
available again is a high priority.
Anyone know how to check the MySQL tables for the uniqueness attribute?

> If akonadi uses 1-xyz internally as unique ids that's fine but using it to
> communicate with other apps does not provide any uniqueness. so for kmail
> it is not a unique-ID.

Well, it is a good approximation since a particular KMail instance only works 
with one particular Akonadiserver instance.

As I wrote before factors like limited resources make it necessary to 
iteratively migrate certain aspects of a setup. Having folder specific metadata 
in a specific client's config file instead of attached to the folder is a result 
of that.

I am confident Laurent would appreciate if anyone would be working towards that 
goal.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
_______________________________________________
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/