MERGE Requests and the WCF Data Services Client

I came across this interesting blog post by Alex van Beek the other day where he demonstrates how to reduce the size of the payload of MERGE requests to an OData service when using the WCF Data Services client. The OData protocol defines a HTTP MERGE action that enables a client to request updates to only specific properties of an entity, which sounds neat and perhaps a way to save bandwidth when updating an entity. But, as Alex points out, the WCF Data Services client library always includes all of the properties of an entity (at least the ones it knows about) in the request.

For example, the following is the payload of a MERGE request sent to a Northwind-based data service.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<entry xmlns:d= 
  <category scheme=
    term="NorthwindModel.Customer" />
  <title />
    <name />
  <content type="application/xml">
      <d:Address>Obere Str. 57</d:Address>
      <d:CompanyName>Alfreds Futterkiste</d:CompanyName>
      <d:ContactName>New Name</d:ContactName>
      <d:ContactTitle>Sales Representative</d:ContactTitle>
      <d:Region m:null="true" />

In this example, even though the only property that I changed on the client was ContactName, all of the properties were included by the client in the MERGE request. Why does the client include all of the properties in the MERGE request payload, even when those properties haven’t changed? As Alex correctly points out, it is because—unlike the ObjectContext in the ADO.NET Entity Framework—the DataServiceContext doesn’t have an ObjectStateManager-like component that tracks property-level changes on the client. All the client can do when an object has been marked as changed is send all of the properties that it knows about to the data service. (From the client’s perspective, the main difference between MERGE and PUT is that because a PUT is essentially an entity replace, any property values that the client doesn't know about are reset to their default values.) These MERGE request payloads can get large when the entity has BLOB properties (although you should really consider streaming BLOBs to an OData service—for more info see my Data Services Streaming Provider series).

By wrapping the DataServiceContext to implement his own property-level tracking, Alex’s example does reduce the payload of MERGE requests (PATCH requests, which will likely be supported in the future) to an OData service. If you think that this functionality should be added to the official WCF Data Services client, you can vote for it now at the WCF Data Services Feature Suggestions site.


Glenn Gailey

Comments (1)

  1. Alex van Beek says:

    Thanks for mentioning my blog post!

Skip to main content