Tag Archives: LINQ

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.

The great data context in the cloud

No, I’m not posting about the ‘death’ of LINQ to SQL, I’m talking about the live framework SDK! I’ve been meandering my way through the MSDN documentation and samples for the framework to check out what’s coming. What excites me the most about what I can see in the MSDN doco is the fact that as the title suggests, using the .Net libraries your mesh becomes like a data context that exists not to interface with your database, but with a datasource either in your mesh, or locally on your machine.

One of the great things here is that you don’t need to care (well, not much…) whether that source is local or remote! With a little bit of ye olde factory pattern, you can get yourself what is called a LiveOperatingEnvironment to work against. As far as I can see, the only downside is the lack of notifications on mesh object changes.

Taking this a step further, we can assume that if the LiveOperatingEnvironment looks like a datacontext, the objects we obtain from queries run against them maintain some sense of state. This seems to hold true thanks to the presence of the Load() and Update() methods on the abstract base class of the mesh objects known as LiveItem. Continuing on the data context path, we can say that to obtain an item from our mesh we can do something along the lines of…

var myMeshObject = (from meshObjects in myLiveOperatingEnvironment.CreateQuery<MeshObject>

select meshObjects).First();

Notice the main difference here from your regular LINQ query is that we’re calling the generic CreateQuery<T> method that lives in our LiveOperatingEnvironment class. This method appears to be the granddaddy of all live queries in the .Net libraries. The generic restrictions mean that you can query and LiveItem inheriting classes – which means just about anything. It returns an instance of the LiveQuery class, which is the object that inherits the IQueryable and IEnumerable interfaces, providing all our LINQ goodness. Moving on from here, if I wanted to say, update the title of my meshObject I would do something along the lines of…

myMeshObject.Resource.Title = "Live Framework SDK Information";
myMeshObject.Update();

It’s so simple! Additional good news is – if you haven’t quite got your head quite around LINQ yet, and you’re keen on making use of the Live Framework there’s also other options. These queries can be run as RESTful operations, through the use of either an ATOMPub library or a JavaScript library. There are some differences in what’s made available, however I haven’t delved much into the JS or ATOM libraries so I won’t comment too much on them here but there’s no reason you can’t go check out the SDK doco yourself over at MSDN!

Expression Trees – Creating and Converting

So you’ve seen LINQ to SQL in action and it looks like voodoo. How does the compiler turn that funny looking query statement that you’ve written in C# and make a working SQL query out of it? There are a couple of other key parts to it, but right in the middle are expression trees, forming the neutral map from which either a lambda statement (which is what your LINQ query breaks up into) or a SQL query can be generated.  Continue reading

LINQ to SQL or LINQ to Entities?

On one of the Readify mail lists there was a question raised about whether LINQ to SQL would support LINQ to Oracle. There was some discussion over if a direct use would work, passing an Oracle friendly connection object to the data context (which accepts an IConnection) or if a 3rd party option was available. I went away for a day or two down to the coast and returned to see another email in the chain pointing out something we hadn’t thought of…

Why use LINQ to SQL at all? Why not use LINQ to Entities! The email also linked to a post that has a nice concise summary of when you should use LINQ to SQL and when LINQ to Entities is appropriate. The blog post is available here, and I recommend that you continue on through to the linked MSDN article for more info (which is available here for quick reference).

Thanks to Chris for the idea and the pointer to this article!

LINQ Queries

The performance of LINQ is a key issue for a lot of people in adopting this new tool in their arsenal. A lot of the time they are particularly interested in how LINQ to SQL performs in comparison to a traditional ADO.Net query. The news isn’t all bad. Under the covers LINQ to SQL has to use something to retrieve data, so it’s naturally going to be slower than a direct query mechanism such as ADO.Net. They key here is remembering that LINQ to SQL isn’t just a query tool. It’s an ORM solution, a rapid development tool and a more natural way to query all rolled into one.

Continue reading