Bug 84710

Summary: Contacts are being treated as updated and written to database, but their content did not change
Product: SyncEvolution Reporter: Mateusz Polrola <mateusz.polrola>
Component: SyncEvolutionAssignee: Patrick Ohly <patrick.ohly>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: highest CC: syncevolution-issues
Version: 1.4   
Hardware: Other   
OS: All   
i915 platform: i915 features:
Attachments: Synchronization log
Sample vcard
Sample vcard
Sample vcard
Sample vcard

Description Mateusz Polrola 2014-10-06 10:10:39 UTC
When using version, synchronizing phone after initial sync finishes with updated contacts, but their content did not change since last synchronization.
Comment 1 Mateusz Polrola 2014-10-06 10:13:06 UTC
Created attachment 107410 [details]
Synchronization log

With loglevel=4
Comment 2 Mateusz Polrola 2014-10-06 10:13:34 UTC
Created attachment 107411 [details]
Sample vcard
Comment 3 Mateusz Polrola 2014-10-06 10:13:47 UTC
Created attachment 107412 [details]
Sample vcard
Comment 4 Mateusz Polrola 2014-10-06 10:13:57 UTC
Created attachment 107413 [details]
Sample vcard
Comment 5 Mateusz Polrola 2014-10-06 10:14:10 UTC
Created attachment 107414 [details]
Sample vcard
Comment 6 Patrick Ohly 2014-10-06 10:49:38 UTC
This is most likely an undesired side effect of this performance-enhancement commit:

commit a2e990e51fbdff04b12ab881f2348c42eb3bc535
Author: Patrick Ohly <patrick.ohly@intel.com>
Date:   Wed Sep 10 10:52:10 2014 +0200

    PBAP: use raw text items
    This avoids the redundant parse/generate step on the sending
    side of the PBAP sync.

What I had not taken into account is that the parse/generate step is important for the item comparison during a cache sync.

I need to think some more about a proper way to solve this, and also ensure that I have automated test coverage for this kind of failure.

In the meantime, can you try with the commit above reverted? The majority of the performance enhancement in was elsewhere, so it shouldn't add back that much overhead.
Comment 7 Mateusz Polrola 2014-10-06 11:27:25 UTC
With this commit reverted, issue is no longer reproducible.
Comment 8 Patrick Ohly 2014-10-31 07:24:50 UTC
A better solution based on an enhanced comparison (RELAXEDCOMPARE()) was implemented in 1.5, without reverting the performance enhancement.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.