Sync success accept function

[hgray]

I'm trying to write code to handle more complex conflict resolution on the client. Currently you have callback methods for sync conflict, dataset deletion, and dataset merging. All of these can interrupt the process by returning a false and are called prior to the data being committed.

I was wondering if it would be possible to add the same for a sync success. The way a success is currently set up, we get a list of which records are added + updated, but by the time we get that, the records have already been written to the database. We don't have an easy way to determine what changed or which ones are being added. If we could assign a callback, we could run custom logic and then determine whether each record should be committed or not.

As a side note, it might also be nice to separate AddedRecords from UpdatedRecords, again to simplify processing of new data.

[hgray]

Actually, thinking about it more, what would probably be easiest to implement on your end and would serve the purpose is to have the same flow as the conflict handling. We would get a list of all of the records which are being added/updated prior to them being committed to SQL. We could accept, modify, or remove them and then resolve with a list of what we want to commit. I'll see about working this out in a pull request.

[behrooziAWS]

Can you explain a use case why you would want to alter a non-conflicting record before updating it in the local datastore? It seems overriding with a device specific value defeats the purpose of sync because all devices should have the same value.

[hgray]

A simple accumulation value with offline play will give a good example.

Device A plays offline five times and stores a value of 5.
Device B plays online 3 times and syncs a value of 3 to the cloud.
Device A comes online. Cloud says 3, I say 5, but the real answer is 8 (5+3)

For my implementation, I will be storing not only the perceived actual value (5 on Device A, 3 on Device B), but also the delta that I'm applying to the value. That way if the cloud gives a value, and that value didn't originate from my data, I can append the delta and resync.

Please let me know if you'd like to talk through this in more detail.

[behrooziAWS]

This seems like it may be better solved by lambda functions. To make this work, one approach is to have 2 keys, totalTimes and deviceTimes. When device A comes on line, it will send deviceTimes=5 to the cloud. In your lambda function you would take the value of deviceTimes and add it to totalTimes so totalTimes will now be 8 and reset deviceTimes to 0. What comes back to the device is totalTimes=8 and deviceTimes=0. We are in the process of modifying the record format to make this easier, so you may want to hold off until we do, but this http://mobile.awsblog.com/post/Tx31I7KB4XXQUL3/Introducing-Amazon-Cognito-Events-Sync-Triggers talks about the feature. Would this work for you?

[hgray]

We have looked at Lambda Cognito events, and will likely migrate to that solution soon. At this point, we're looking to solve this on the client side. Doing the simple changes suggested in my pull allows the flexibility of processing them prior to SQL commit so we have the ability to manage the sync, much like the conflict sync and has the added benefit of avoiding performing two writes to the DB.

[hgray]

Incidentally, I should mention that some of my Lambda tests have resulted in a non-recoverable sync conflict error which Albert is currently looking into on this thread: #48

[behrooziAWS]

Yep, we are investigating that issue. One thing to mention is that if you do something like this locally and then want to migrate to lambda, the migration story gets a bit more interesting because some devices may be running the local logic still.

[hgray]

I have a plan for that :)

[karthiksaligrama]

Move to feature requests https://github.com/aws/aws-sdk-net/blob/master/FEATURE_REQUESTS.md