Bug 84710 - Contacts are being treated as updated and written to database, but their content did not change
Summary: Contacts are being treated as updated and written to database, but their cont...
Status: RESOLVED FIXED
Alias: None
Product: SyncEvolution
Classification: Unclassified
Component: SyncEvolution (show other bugs)
Version: 1.4
Hardware: Other All
: highest normal
Assignee: Patrick Ohly
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-06 10:10 UTC by Mateusz Polrola
Modified: 2014-10-31 07:24 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Synchronization log (2.85 MB, text/plain)
2014-10-06 10:13 UTC, Mateusz Polrola
Details
Sample vcard (303 bytes, text/plain)
2014-10-06 10:13 UTC, Mateusz Polrola
Details
Sample vcard (325 bytes, text/plain)
2014-10-06 10:13 UTC, Mateusz Polrola
Details
Sample vcard (311 bytes, text/plain)
2014-10-06 10:13 UTC, Mateusz Polrola
Details
Sample vcard (321 bytes, text/plain)
2014-10-06 10:14 UTC, Mateusz Polrola
Details

Description Mateusz Polrola 2014-10-06 10:10:39 UTC
When using version 1.4.99.4, 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 1.4.99.4 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.