Versioning Schema Changes for WCF Data Services

I recently investigated an issue for a customer around how to handle schema changes when their data was exposed using WCF Data Services.  By default, if you add a column to a database table and refresh the Entity Data Model without updating the client-side service reference, the client is not able to load the entity properly because of the new property contained in the model. 

There are several situations where this is undesirable and annoying.  The first scenario is a project under active development.  Every time there is a schema change to the database, each developer must resync their reference to make sure their entities materialize properly.  A second scenario occurs when you have multiple client applications depending on the WCF Data Service, but you are only updating one of the applications with new functionality that required a schema change to the source data.  By simply adding a column, previously working applications would now be broken.

There are recommendations for each of these scenarios.  In the first scenario, you can set the DataServiceContext.IgnoreMissingProperties property to true.  When this property is set to true, materialization succeeds when properties from the type cannot be mapped to properties of the client-side type.  In the second scenario, it is more advisable to create multiple versions of the Data Service.  Using the first workaround in the second scenario would require a large regression test of all existing client applications against the modified service.  In this case, versioning your Data Services is the current recommendation.

Comments

• Anonymous
  January 16, 2011
  How do you versioning your Data Services ?

• Anonymous
  January 16, 2011
  To version your Data Services create multiple versioned services. · V1/Service.svc · V2/Service.svc Each version can then be accessed by the application using it.  Once a versioned service is no longer available, remove it.