[SyncEvolution] syncevolution debug help needed
Patrick Ohly
patrick.ohly at intel.com
Tue Aug 23 06:53:32 UTC 2016
On Tue, 2016-08-23 at 00:29 +0200, deloptes wrote:
> Patrick Ohly wrote:
>
> > Is the full code available somewhere?
> >
>
> No, I still don't know what to do with it and I'm not sure in which form I
> should upload it. Uploading it means maintain it ... etc. I was thinking to
> upload it to the trinity desktop, but still it is not clear how it would
> fit with the different distros. Another option would be to add it to
> syncevolution - perhaps it is even more proper ... anyway short answer is
> no - I could pass a zip file of it .. it's really not much code.
> The last but not least is I do not feel confident because of this issue and
> do not want to "release" is until it is solved.
Fair enough. The common wisdom is to "release early, release often", but
in this case I agree that it is better to ensure that there is no data
loss before making it available to others.
> So it looks like I misunderstood the ITEM_REPLACED meaning? Could you
> please confirm once again. I have been struggling with these part of the
> code for some time already.
>
> My questions
> 1. even when update is implemented as del+add and the item has the old ID it
> should return ITEM_OKAY?
Yes.
> 2. does ITEM_REPLACED means that item has new ID and is to replace the old
> item with the old ID?
ITEM_REPLACED, ITEM_MERGED and ITEM_NEEDS_MERGE all are to be used only
when adding a new item, i.e. uid is empty. In this case, the engine
doesn't know about the existing item in the database and the backend has
to tell the engine about it.
ITEM_NEEDS_MERGE is probably best for handling this situation because
merely replacing the existing item (ITEM_REPLACED) can loose data and
merging in the backend (ITEM_MERGED) is more work to implement.
> Strange is only that I have such issues with calendar+todo only and a fact
> is that it messes totally up in slow sync.
Not sure either. Perhaps it is because calendar items have a UID and
thus additional constraints that don't apply to contacts. ITEM_REPLACED,
ITEM_MERGED and ITEM_NEEDS_MERGE should never be needed for contacts,
because a contact backend typically will never be able to detect when a
new contact that is to be added already exists.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
More information about the SyncEvolution
mailing list