Sync Offline Table Conflict Example

[atexinspect]

Hi Adrian,
I am updating a legacy application that uses your previous Microsoft.Datasync.Client/Microsoft.Datasync.Client.SQLiteStore V6.1.0
packages. Previously during a sync I could do something similar to the below code and always revert to the servers version on a conflict.
Have you an example of how to do this using the new Community Toolkit version? I am struggling to figure it out.

Thanks
Paul.

https://learn.microsoft.com/en-us/previous-versions/azure/developer/mobile-apps/azure-mobile-apps/howto/client/dotnet

public async Task SyncAsync()
{
    ReadOnlyCollection<TableOperationError> syncErrors = null;

    try
    {
        foreach (var offlineTable in offlineTables.Values)
        {
            await offlineTable.PushItemsAsync();
            await offlineTable.PullItemsAsync("", options);
        }
    }
    catch (PushFailedException exc)
    {
        if (exc.PushResult != null)
        {
            syncErrors = exc.PushResult.Errors;
        }
    }

    // Simple error/conflict handling
    if (syncErrors != null)
    {
        foreach (var error in syncErrors)
        {
            if (error.OperationKind == TableOperationKind.Update && error.Result != null)
            {
                //Update failed, reverting to server's copy.
                await error.CancelAndUpdateItemAsync(error.Result);
            }
            else
            {
                // Discard local change.
                await error.CancelAndDiscardItemAsync();
            }

            Debug.WriteLine(@"Error executing sync operation. Item: {0} ({1}). Operation discarded.", error.TableName, error.Item["id"]);
        }
    }
}

[adrianhall]

I don't right now. However, it should be easy to do as we don't hide the tables any more. Short version:

1. Remove the operations queue entity that failed.
2. Use the HTTP client to pull the server side version and insert into the local table.
3. Call SaveChanges with the "add to operations queue" flag set to false.

Something like:

using var context = GetDbContext();
foreach (var failedRequestKV in pushResult.FailedRequests)
{
  string operationId = failedRequestKV.Key;
  DatasyncOperation operation = context.DatasyncOperationsQueue.SingleOrDefault(x => x.Id == operationId);
  // operation has the ItemId and EntityType of the entity change that is queued.
  // Item is the JSON representation of the client-side value; you can also get the client side value from
  // the database.

  ServerResponse response = failedRequestKV.Value;
  // response is actually a ServerResponse<T> where T is the EntityType as a type.
  // response.Content is the JSON representation of the server-side value
  // (response as ServerResponse<T>).Value is the server side value.
  
  // You now have both client side and server side in both JSON and concrete values.  Do the necessary updates
  // and then do the following:

  // Delete the operations queue request
  context.DatasyncOperationsQueue.Remove(operation);
  // Save changes without updating the queue
  await context.SaveChangesAsync(true, addToQueue: false);
}

Obviously, this is a lot of pseudo-code. I'm happy to consider design changes here. Perhaps, when we create the Offline Options Builder, we do something like:

protected override void OnDatasyncInitialization(DatasyncOfflineOptionsBuilder optionsBuilder)
  {
    options.UseEndpoint(new Uri("https://MYENDPOINT.azurewebsites.net"));

    options.Entity<Movie>(cfg => {
      cfg.ClientName = "movies";
      cfg.Endpoint = new Uri("/api/movies", UriKind.Relative),
      cfg.Query.Where(x => x.Rating != MovieRating.R)
      cfg.ConflictHandling = ConflictHandling.UseServerEntity;
    });
  }

Basically, ConflictHandling would have one of three values:

• UseClientEntity will always overwrite the server entity (no version checking)
• UseServerEntity will always overwrite the client entity if there is a conflict
• Custom will be the default and will add the transaction to the FailedRequests list.

Thoughts on this?

[atexinspect]

Thanks for the reply. I will give it a go. Paul.

[Vroomer]

I'm a big fan of having the DatasyncOperationsQueue accessible, but I really don't understand what we are supposed to do without CancelAndUpdateItemAsync/CancelAndDiscardItemAsync. I'm synchronizing something like 30 different tables and I need to have individual error handling for some of them. What is the generic ServiceResponse type good for, if we don't know the entity's type, apart from the EntityType string? Using some convoluted reflection just to be able to access the DbSet and deserialize the item seems like a really bad design choice. Besides it would just cause problems with trimming. I really wish to have some simple way to access DbSet from ServiceResponse/DatasyncOperationsQueue that would use source generation under the hood. Am I missing something?

The only alternative I can think about right now is to never push all tables by calling PushAsync() and instead push them one by one explicitly by type through some generic method wrapper, which would preserve the types and handle the errors.

[adrianhall]

… hence why I am working on a new “conflict handling” mechanism.

[adrianhall]

See Issue #298 for the discussion and ultimately implementation of the conflict resolution.