Tickets :: Comment on [#12175] Add modification sequence support to Horde

* Your Email Address
* Spam protection	Enter the letters below: __.. ..__..__ .__. (__ \|__\|\| \|\| \\| \| .__)\| \|\|__\\|__/\|__\
Comment	>>> 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. >
Attachment
Watch this ticket