Delta Queries (Part 3)

[Paul_todd]

Hi,

 

The next piece of the Delta Queries puzzle is identifying deletes on the backend service collection. In order to do highly efficient change detection you need to be able to detect when a record has been removed from the collection on the server. Whilst it is possible to query the collection for a list of ids and then partiion the collection into new, modified and deleted records on the client based on a timestamp or a version key, this is highly inefficient on a mobile device.

 

When delta queries were envisaged delete was a core use case envisaged to make synchronization efficient between the server and the clients.

 

To delete the travel agency we do a standard REST call with an HTTP verb of DELETE. As in the previous sample I have not included any of the details around CSRF protection which may or may not be enabled on your system.

 

URL:

<my service root>/TravelAgencies_DQ('04051971')

 

ACTION:

DELETE

 

HEADERS:

 

The response back is:

204 - No Content

 

But what is really interesting is when we query the service we get back a new document with the deleted record in it. This is called the tombstone record and is specified very simply:

 

<at:deleted> is an element that specifies the resource that was removed from the collection as well as the date it was removed. This is an IETF extension to the ATOM protocol and if you are interested in finding out more about the semantics of this mechanism you can look at the link here

 

However back to our delta query requests. In the previous sample we got back a new token which we can use now to get the changes since we last requested a delta change. As expected we get back a new ATOM document with a deleted tombstone marker in it:

 

 

<feed

xmlns="http://www.w3.org/2005/Atom"

xmlns:at="http://purl.org/atompub/tombstones/1.0"

xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"

xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xml:base="<my service root>">

    <id><my service root>/TravelAgencies_DQ</id>

    <title type="text">TravelAgencies_DQ</title>

    <updated>2014-03-10T14:17:16Z</updated>

    <author>

    <name/>

    </author>

    <link href="TravelAgencies_DQ" rel="self" title="TravelAgencies_DQ"/>

    <at:deleted-entry ref="<my service root>/TravelAgencies_DQ('04051971')" when="2014-03-10T14:17:16Z"/>

    <link rel="delta" href="TravelAgencies_DQ?!deltatoken='12313D220A3A1EE3AA8A133BE813AF0F_20140310141716'"/>

</feed>

 

Here the specific element we are interest in is the "at:deleted" element which tell us that the entity with the key '04059171'  was deleted at the attribute specified by "when"

 

Of course as expected we also get back another delta token and if we query with that token, well we get back an empty feed which is what was to be expected.

 

 

This concludes the three part document on delta queries. The next set of articles will involve building a synchronization solution in javascript to show how delta queries can efficiently take the havy lifting out of building a synchronization solution on any platform.