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:	SyncEvolution	Assignee:	Patrick Ohly <patrick.ohly>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	highest	CC:	syncevolution-issues
Version:	1.4
Hardware:	Other
OS:	All
Whiteboard:
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 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.