Syncing a local store

[lsmilek1]

May I ask what strategy you picked? Relying on last updatedAt field seems to be problematic when let’s say two persons are updating the same objects, but they change a different field. For example:

1. User A modifies fieldA = 20 and is in poor connectivity area. He keeps the fieldB = 50 untouched.
2. Meanwhile a user B sets fieldB = 55, before the User A gets connected
3. User A then gets signal and rewrites the fields back or if strictly checked by passing a “saving date” inside context the update could get rejected in beforeSave with message that newer object is available. But in that case the update on fieldA is getting lost, as the most recent state wins and that state does not have fieldA updated

I was thinking about having separate updatedAt for each field in nested object as mentioned here.

@lsmilek1

As I noticed, the request.object in the beforeSave is already modified. I am investigating the following concept of last update wins:

0. object in database has a nested object with fields and related last update dates. for example
   "updated" { "age": "2021-05-7T12:00:00.000Z", "otherField": "2021-05-7T12:00:00.000Z", ... }
1. user A send modified fields with ParseSwift .save() and in context would be a date set (basically when that update was triggered, and can be also an old date in case or poor connectivity
2. in the beforeSave trigger the function would go through the dirtyKeys and compare if the date in context is larger than the one in related updates.otherField
3. if the context date is lower, it means that the value was updated by a newer one. In this case I would need to throw away that particular field’s update
4. if context date is larger, the updates.otherField date gets set to the same value as in the context

But I am not sure if that is a reasonable way and would make rather more sense to go for VectorVersions (seems difficult when I have fields not as Strings, just numbers for later ElasticSearch indexing)…