[SyncEvolution] SyncEvolution in Fremantle

[Ove Kaaven]

Patrick Ohly skrev:
> Looking at the code again and in particular
> SyncSourceRevisions::updateRevision(), I remembered one problem with the
> "changes since last sync" approach of change tracking. Suppose the
> following chain of events:
>      1. sync starts at time T1, with no local changes
>      2. a changed item A is sent by the SyncML server and updated
>         locally
>      3. the user edits a different item B while the sync runs
>      4. sync ends at time T2
> 
> Now in the next sync, which time stamp should be used to find changed
> items that need to be sent to the server?
> 
> When using T1, the changed item A would be sent to the server, which is
> wrong (additional traffic, unnecessary risk of conflicts on the server).
> When using T2, the locally modified item B would not be sent.
> 
> Updates of the database would have to be disabled while a sync runs to
> avoid this problem. Is that possible?

I don't think so. I think this is why I originally was talking about
improving on TrackingSyncSource, not about replacing it; then I could
make the backend retrieve all IDs modified after time T1, and then
TrackingSyncSource would check which of these IDs has already been
synced the same way as it currently does. I'd expect that to still be
much faster than checking every ID in the whole database.

>>> Do you have easy access to all IDs of existing items? This is necessary
>>> to detect deleted items.
>> Sure, a full list of IDs can be queried easily, with minimal overhead
>> (unlike their associated last-modified-times). I'm not totally sure
>> whether deleted IDs are included or not, though, might have to test.
> 
> They don't have to when we keep a list of known IDs in the last sync.

The point was that it could be a problem if it did include deleted IDs,
since if it did, there'd be no way of distinguishing it from a
non-deleted ID without doing additional database queries (like querying
the list of deleted IDs with getAllDeletedItems(), and
cross-referencing, or something). Hopefully getIdList() doesn't include
the deleted IDs then; it probably doesn't, but I can't be sure until I test.