Conflicts will really depend on the type of the datasource. I have done spike when I added additional wrapper and evaluated how conflicts can be passed to the mobile layer.
h4. Spike
I have added new error type on the server that can be retrieved on the client and logged as conflict. This conflict then will need to be handled by application developer by notifying end user that his data may be not up to date and force cache refetch.
As for actual detection of the conflicts we could introduce data change detection mechanism based on deltas, however this is how old sync worked and it had a lots of overhead alternatively we can introduce version field, but without transaction/locking the row we cannot guarantee any writes at the time when read and write is happening. Passing over version in mutations we do not define is also tricky enough. We cannot force users to include versions in their mutations and it will be mostly pattern rather than something that could work out of the box.
{code}
if (msg.what == "conflict") {
MutationObject interceptorObj = (MutationObject)msg.obj;
conflictResolver.resolveConflict(conflictResolutionHandler,
interceptorObj.serverState,
interceptorObj.clientState,
interceptorMessage.requestIdentifier,
interceptorMessage.requestClassName);
}
{code}
h4. Solution
Use DB transactions creationDate and concept of root resolver templates that will be always append specific fields for the data. Core problem of the mutation is that we cannot assume any dataset - we can have postgress specific triggers but they not going to work with non relational db's
h4. Should we really build conflict generic resolution mechanism abstracting from data source?
Most of the solutions like firebase totally ignore fact of the conflicts. Apollo itself abstract from data layer.
Last write wins is common strategy and it is perfectly fine for most of the cases.
Application should be designed to handle conflicts properly.
Instead of setVotes(getVotes()+1) users should provide mutations that increment amount of votes on the server and are totally detached from the data on the client. Users can avoid conflicts by using mutations with data that was only changed by user instead of writing and assuming that entire file was changed.
|
|
