https://bugs.meego.com/show_bug.cgi?id=23744 pohly <patrick.ohly(a)intel.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #1 from pohly <patrick.ohly(a)intel.com&gt; 2011-11-17 14:38:07 UTC --- commit fb17daa54867623bba26225e480fa5564d6ac595 Author: Patrick Ohly <patrick.ohly(a)intel.com&gt; Date: Mon Oct 24 18:05:30 2011 +0200 phone sync: delete<->delete conflict + phone calendar+todo sync (BMC #23744) When deleting an item on phone and locally, the next sync fails with ERROR messages about "object not found". This has several reasons: - libsynthesis super data store attempts to read items which may or may not exist (triggers ERROR message) - it checks for 404 but Evolution backends only return a generic database error (causes sync to fail) It turned out that ReadItem and DeleteItem are expected to return a 404 status when the requested item does not exist. This patch documents that (only in the TrackingSyncSource, though), adds tests and fixes EDS, WebDAV, file and sqlite backends accordingly. This patch also suppresses the 404 error logging inside DeleteItem(), while still returning that error code to the Synthesis engine. Not logging that particular situation is consistent with the previous SyncEvolution behavior of silently returning successfully when there wasn't anything to delete. In addition, more recent libsynthesis versions also no longer do a ReadItem() call to test for existence. That would still trigger a spurious (albeit now harmless) ERROR message. (cherry picked from commit ba289c899ffc4f0f0f247ab0f622bf94db421741) commit 1abcf4d7bbaeb0c72a4748c4ec6299788851797a Author: Patrick Ohly <patrick.ohly(a)intel.com&gt; Date: Fri Oct 28 15:42:57 2011 +0200 server engine: more efficient deletion in superdatastore Attempting to read an item just to check whether it exists is expensive. It also may trigger error messages when the item does not exist (done by SyncEvolution). Therefore, if a data store is able to properly report whether it found the item which is to be deleted, a different logic is used for deletion in the superdatastore: - attempt to delete until it succeeds in a subdatastore - recreate the sync item from the copy after a failed delete attempt (which deletes the sync item), if there is another loop iteration Deleting the copy of the sync item was moved to the function exit code to avoid code duplication. By default all data stores are assumed to not support 404 in its delete operation. The only exception is the plugin API. The (somewhat undocumented) assumption is that all methods properly report 404 when the requested item does not exist. The "attempt to read" code already relied on that. Now the code relies on that for the "attempt to delete". Probably it even works when the plugin returns some other error code (the "regular" value will be false in that case) or no error code at all: the translation code between remote ID and local ID will already detect that the item is not in the mapping table if it is not in the subdatastore. So the actual plugin will not get called at all in the case where its expected behavior would matter. -------- Product: SyncEvolution Component: SyncEvolution MeeGo Release: unspecified Severity: normal Priority: Medium Keywords: Status: RESOLVED Who: patrick.ohly(a)intel.com Assigned To: patrick.ohly(a)intel.com Target Build: 1.2.1 Flags: Changed: Status Resolution -------- https://bugs.meego.com/show_bug.cgi?id=23744 -- Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.