The great data context in the cloud part II – synchronisation

In my last post I wrote about how simple mesh objects look to work with. This is of course, assuming you’re not intending on sharing them with anyone. With that said, what’s the point if you don’t show your neighbour a little love and invite him in on the mountain of TFS resources you’ve been accumulating over the years!

So you send your mate and invite, he accepts and the first thing he does is decides he doesn’t like what you’ve name the TFS Installation Help.chm file that exists in your now shared mesh folder. So he goes ahead and updates the title. At the same time, you decided that really you didn’t like it either. So you go ahead and change it as well. The time comes, and mesh decides it will sync your changes to storage. Assuming of course that you are both connected, and both sync to the mesh there is going to be a conflict!

With that in mind, how can we first detect and then resolve conflicts during synchronisation in the Live Framework? We’re going to start by investigating our old friend MeshObject. Lets think of our MeshObject as a folder in our mesh. For this example, it’s our TFS folder. Looking at the Resource model exposed in the Live Framework we can see that our TFS folder (Mesh Object) has a child collection of DataFeedItem. These are the documents, pictures etc. etc. that make up the contents of your folder. On that collection we find a property called SyncEntries. This is a feed of all the synchronisation info that exists between your client, and the mesh, and this will be our query point to work out which bits have conflicts, and how we’re going to resolve them.

The first step is to identify that there is a conflict. We can do this simply by doing the following

var conflicts = (from syncItem in myDataFeed.SyncEntries.Entries
where syncItem.Resource.Sync.Conflicts.Count > 0
select syncItem);
if (conflicts == null)
return;

So now we have a nice gate clause on our logic that makes sure we have some conflicts before we attempt to resolve them. Now we know that we have conflicts, and thanks to LINQ we have the actual conflicting items we need to decide on a strategy for handling the conflicts. In this case for simplicity sake, we’re going to just call the ResolveConflict method that exists on the FeedEntry object that we’ve got from our query. This makes our code something like this…

var conflicts = (from syncItem in myDataFeed.SyncEntries.Entries
where syncItem.Resource.Sync.Conflicts.Count > 0
select syncItem);
if (conflicts == null)
return;

foreach (var conflictingEntry in conflicts)
{
     conflictingEntry.ResolveAllConflicts()
}

We could have also called ResolveConflict on each conflict in the entry, or marked the item as the winner and then from what I can infer (as the doco is a little light here still) we would call update on the item and let the mesh resolve the issues.

So – that’s synchronisation with the cloud. Unfortunately I can’t find too much in the MSDN doco on the exact behaviours used by the ResolveConflict methods at this point, or the intended usage of the mark as conflict winner method but the live framework walkthrough seems to suggest that an Update should be actioned after these methods are invoked.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s