[Kde-pim] Proper way to sync collection moves

[Krzysztof Nowicki]

Hi,

I have been revisiting this lately after some break caused by lack of time for 
development. 

I have rewritten the code to use HRIDs which meant providing the full parent 
chain up to the root. Unfortunately providing fake parents won't work and the 
only way to get it right is to fetch the actual parents and provide them real 
collections.

While general sync works, I am still seeing the same issue, i.e. a new 
collection is created for the moved folder in its new destination, but the old 
one stays.

I guess I'll have to dig further.

Regards
Chris

On środa, 11 maja 2016 08:08:36 CEST Daniel Vrátil wrote:
> On Tuesday, May 10, 2016 3:27:53 PM CEST Krzysztof Nowicki wrote:
> > Hi,
> > 
> > W dniu 2016-05-10 13:32:40 użytkownik Daniel Vrátil <dvratil at kde.org>
> 
> napisał:
> > > On Tuesday, May 10, 2016 12:07:19 PM CEST Krzysztof Nowicki wrote:
> > > > Hi,
> > > 
> > > Hi,
> > > 
> > > > I've been debugging some collection sync issues in the EWS resource
> > > > and
> > > > I
> > > > wonder what is the correct way to tell Akonadi that a collection was
> > > > moved.
> > > > 
> > > > What happens now is that when I move a folder from one parent to
> > > > another
> > > > I
> > > > receive a notification from Exchange that the moved folder has
> > > > changed.
> > > > This triggers a collection tree sync for the resource. The EWS
> > > > resource
> > > > then retrieves the details about the folder including the new parent
> > > > collection. It then creates an empty local collection for the folder,
> > > > populates it with data and also creates an empty collection for the
> > > > parent folder only to give an indication about the parent remote id.
> > > > Finally it uses
> > > > collectionsRetrievedIncremental() to deliver the updated collection.
> > > > 
> > > > Unfortunately what I see is that Akonadi creates a new collection
> > > > under
> > > > the
> > > > new parent instead of reparenting the existing collection. The old
> > > > collection is not deleted, which leads to two collections with the
> > > > same
> > > > remote id. I was expecting that it would figure out that there is
> > > > already
> > > > an existing collection with the same remote id and would update it
> > > > instead
> > > > of creating a new one.
> > > 
> > > Using Hierarchical Remote IDs (HRIDs) should help so try enabling
> > > ResourceBase::setHierarchicalRemoteIdentifiersEnabled(). With HRIDs the
> > > CollectionSync will always consider the parent collection chain when
> > > resolving move. Without HRID, just having "kde-pim" as an identifier
> > > could be ambiguous. But when you enable HRID Akonadi will also consider
> > > parent RemoteID, thus disambiguating "kde-pim" collections in
> > > "INBOX/ml/kde-pim" and "INBOX/commits/ kde-pim"
> > > 
> > > Looking into CollectionSync, the move detection path is only enabled
> > > when
> > > HRIDs are enabled, so try that.
> > 
> > When I turned on RHIDs I actually noticed that the incremental sync
> > doesn't
> > work at all. Do I assume correctly, that in case of RHIDs when I sumbit a
> > changed folder I need to provide the full collection chain up to the root?
> > Otherwise the CollectionSync is unable to construct the absolute RID for
> > the collection.
> 
> Yeah, that's probably correct. I think you don't need to provide real
> collections though, you just need to fill the RemoteID of the parents.
> 
> Dan
> 
> > Chris
> > 
> > > Dan
> > > 
> > > > Is there something I'm doing wrong?
> > > > 
> > > > Regards
> > > > Chris
> > > > _______________________________________________
> > > > 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/


_______________________________________________
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/