Store modseq with the synckey


Store modseq with the synckey

We store the modseq info belongs to the synckey because we want to be
able to list the changes since the last sync.
By storing the modseq info with the synckey we make sure that the
modseq info remains available as long as the sync key is relevant,
and is then automatically cleaned up with the sync key.

This in particular fixes the cases where a sync request is sent multiple
times, where previously we would overwrite the modseq info after the
first attempt, and subsequently fail to return the changes.

I opted for the generic "extraData" approach, instead of changing the
modseq table with a foreign key constraint on the synckey (which would
also work I think), because I suspect we'll need the same thing for dav.
Performance wise I don't think it matters either way.


  • We should probably further remove the idea that we are syncing "time windows". We're really syncing based on sync-key entries with some metadata (modseq, dav's equivalent, worst case fallback to timestamps).
  • The "getExtraData()" approach to store modseq is a bit convoluted, this could perhaps be solved better with some refactoring.

Differential Revision: https://git.kolab.org/D4662


mollekopfAuthored on Mar 11 2024, 4:45 PM
mollekopfPushed on Mar 12 2024, 2:39 PM
Differential Revision
D4662: Store modseq with the synckey
rS1ada8e248093: Test an invalid sync key
Build Status
Buildable 46785