The modseq table expects the device primary key, not the deviceid
Don't forget changes while counting changes
If we update modseq whenever we retrieve the changes,
we have to at least not update if we just count.
This is either way super fragile.
Test for flag change retry.
Test an invalid sync key
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.
Notes:
* 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.
Validate changes from tests
Explicit handling of modseq absence
We throw an error and thus force a resync. Modseq must be availble like
this.
Instead of the extra lookup, cache the actually used modseq state
A dummy migration path that simply ignore changes
Suboptimal but avoids a full resync for everything. Given that this
maintains the status quo of missing changes, I suppose it's alright.
In some cases we still have to to fetch modseq
Test flag changes
Test emptySync and flag change
The modseq table expects the device primary key, not the deviceid
Don't forget changes while counting changes
If we update modseq whenever we retrieve the changes,
we have to at least not update if we just count.
This is either way super fragile.
Hiding errors makes this very hard to troubleshoot
Test for flag change retry.
Test an invalid sync key
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.
Notes:
* 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.
Validate changes from tests
Explicit handling of modseq absence
We throw an error and thus force a resync. Modseq must be availble like
this.
Instead of the extra lookup, cache the actually used modseq state
A dummy migration path that simply ignore changes
Suboptimal but avoids a full resync for everything. Given that this
maintains the status quo of missing changes, I suppose it's alright.
In some cases we still have to to fetch modseq
Test flag changes
The migration path doesn't make sense