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

* Your Email Address
* Spam protection	Enter the letters below: .__..__.. .. .._. [__]\| \|\|\/\|\|\ \| \| \| \|\|__\\| \|\| \\|_\|_
Comment	> >> I'm not sure if the listBy() / getChanges() horde app API should >> include a change if it's exactly on the desired end timestamp or not >> (history_ts <= $end_ts). If not, we should do a "thisSyncTS+1" query >> in the ActiveSync backend. > > Yes, it absolutely should. Otherwise that exact timestamp will never > be included since the start_ts is always excluded. > >> But there is more :) Here's a short dump from my history database: > > <snip log> > >> As you can see there are several entries with the same change >> timestamp. An ActiveSync client might query for "history_ts < >> 1365669188" and only see the first entry (id: 811). The delete >> request via the web UI is still running and adds the second delete >> request to the history database also with ts = 1365669188 (id: 812). >> The ActiveSync client will miss this one as it already queried for >> all changes up to 1365669188. Classic race condition :) >> >> Any idea how to fix this one? A monotonic counter would be best but >> that's a rather intrusive change. > > This one is rather trickier. Ideally, all entries with the same ts > should be written as an atomic action, and be guaranteed to be > completed by the indicated ts. This is obviously not the case here > though. We could change both the start and end ts to be inclusive in > the query, though as you said, this would lead to changes potentially > being picked up more than once. We could possible keep track of the > UIDs of messages that have been changed on the last SYNC response, > and exclude them if they occurred on the exact ts boundary. I have no > idea if the current code would support this though (I don't have > access to code at the moment). > > The other possibility would be to somehow track the most recent > history id detected. Though I really don't like this approach since > it means the client code would need knowledge of how they history > system functions - and it assumes any history backend would both have > some unique entry identifier, and those identifiers are numeric (or > at least increase in some numeric-like fashion). > > Both approaches would require some API changes to both the activesync > code as well as the history code in order to provide the needed data > - and such changes would need to maintain BC. > >
Attachment
Watch this ticket

Saved Queries