[Tickets #12175] Re: ActiveSync misses changes from history database

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12175
------------------------------------------------------------------------------
  Ticket             | 12175
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | ActiveSync misses changes from history database
  Queue              | Synchronization
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2013-04-11 15:01) wrote:

>> If we now also store which highest 'history_id' we've seen during the
>> last sync,
>> it will act as a monotonic counter.
>
> Missing sentence: We can remove already seen history ids from the  
> database query result
> by cutting off everything below the last seen history_id.

It seems our replies crossed paths...

Anyway, I don't thing this approach is the way to go.  I feel this is  
more of a work-around than a solution.  As explained in my response,  
this would require client knowledge of the internals of the history  
backend or would require any history backend to expose another  
numerically incrementing counter - neither of which is a current  
requirement.

Also this is duplicate functionality to timestamps which are  
essentially a numerically incrementing value. I think the correct way  
to fix this would be to ensure that entries are guaranteed available  
by the timestamp that it is recorded with. Maybe some "fudge factor"  
added to the timestamp before it is written by the history system to  
be sure it's in the future? A second choice, if this is not desired  
for some reason, would be to decrement the end_ts by some fudge factor  
to ensure any newly written changes are not occurring in the currently  
queried slice of time.