[Kde-pim] Proper way to sync collection moves

[Krzysztof Nowicki]

On niedziela, 24 lipca 2016 11:35:21 CEST Krzysztof Nowicki wrote:
> 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
> 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.

Let me amend myself (sorry for messing up the posting order).

I have done a little more digging into collectionsync.cpp and it doesn't look 
like detecting collection moves is really supported. On one side there is some 
code in CollectionSync::Private::updateLocalCollections() that attempts to 
detect a collection move and issue a CollectionMoveJob, but it only checks 
pairs from the remoteCollectionsToUpdate list. I have traced how these pairs 
are queued on the list and the only place is 
CollectionSync::Private::processCollections(), which only compares remote vs. 
local collections inside a single local collection. This means that unless 
there are some other quirks I'm not aware of the existing code has no chance 
to detect collection moves.

So I'm wondering whether - having been digging into this - it makes sense to 
work on adding such feature to akonadicore or as a fallback handle collection 
moves internally in the resource (by explicitly executing CollectionMoveJob-
s). Given the need for bakwards compatibility with existing Akonadi versions 
I'd have to implement the latter workaround anyway.

Regards
Chris

> 
> Regards
> Chris
> 
> > 
> > > 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/


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