[Kde-pim] How to update the akonadi storage format of KABC::ContactGroup?

[Christian Mollekopf]

On Saturday 18 May 2013 11.00:37 Volker Krause wrote:
> On Friday 17 May 2013 16:51:23 Christian Mollekopf wrote:
> > The only solution I could find is making a ContactGroup2, which should
> > replace ContactGroup for KDE5, maps onto vcard, uses uid's only for
> > references and is supported by the vcard serializer.
> > 
> > I'll then port the kolabproxy to ContactGroup2 as well as all relevant
> > applications in kdepim (kaddressbook, addresseeautocompletion, ...), so
> > they'll support both ContactGroup and ContactGroup2.
> 
> You might want to check how the migration from KCal to KCalCore was done.
> They have the same serialization format, so not sure this is fully
> applicable, but we added payload conversion support for this back then (ie.
> you can ask for both an KCal and KCalCore payload, and it translates via
> the corresponding serializers if necessary).
>

I think I understand the payload conversion, but couldn't find any migration 
code. Was it a gradual conversion?

I have now a ContactGroup2 class, which uses uid's instead of akonadi item 
id's now.

The ContactGroup2 type had to be introduced (as opposed to changing 
ContactGroup), because I have no control over existing client applications 
which expect the akonadi item id to be available in the uid field.

As I couldn't find any way for a one-off conversion of all items, it seems we'll 
have to convert gradually.

There are two ways for gradual conversion:
*  in a resource, i.e. by having the KolabProxy only write ContactGroup2 but 
read both versions and convert accordingly
* by having a serializer from the old format to ContactGroup2, which would 
resolve the akonadi item id's to uid's on the fly, where writing would go 
through the vcard serializer after having added support for ContactGroup2.
(ContactGroup payload => legacy serializer => Akonadi::Item<ContactGroup2> => 
vcard serializer => ContactGroup2 payload)


The second approach would allow to convert all applications to ContactGroup2, 
and drop ContactGroup entirely, instead of having two codepaths all over the 
place.
With UID support in the ItemFetchJob I could also implement the reverse 
conversion for backwards compatibility of external applications which I cannot 
migrate to ContactGroup2.

That whole process seems quite complex to me though, and I'd rather have a 
one-off conversion.... That has the problem thought that it silently "steals" 
all data from non-migrated applications, even if no migrated application is 
used.

Cheers,
Christian
_______________________________________________
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/