ODATA DELTAS Deltas provide a hypermediadriven solution for

  • Slides: 14
Download presentation
ODATA DELTAS Deltas provide a hypermedia-driven solution for retrieving changes to a given set

ODATA DELTAS Deltas provide a hypermedia-driven solution for retrieving changes to a given set of data

WHY DELTAS? • Client Change Tracking • Clients often have local copies of data

WHY DELTAS? • Client Change Tracking • Clients often have local copies of data • Want to figure out what has changed • Large Data Sets • OData is good for retrieving small/moderate sizes of data • OData is not optimized for large data transfer o But is good for returning small/moderate sizes of changes to slowly changing data sets

REQUIREMENTS • Keep it Simple! • 80 -20 rule • Support Web Scale •

REQUIREMENTS • Keep it Simple! • 80 -20 rule • Support Web Scale • Don't require per-client state • NOT designed for multi-master sync • • Service is "truth" Payloads don't carry "exceptions" No per-client state on server Clients don't know about other clients

DESIGN • Server generates opaque "delta link" URL • Generally contains encoding of request

DESIGN • Server generates opaque "delta link" URL • Generally contains encoding of request and "high water mark" so as to avoid per-client state on the server o Multiple clients can maintain their data sets from a single service • Link is returned on the last page of a result • Clients can use link to get newly added, deleted, or changed records • Could be combined with general notification model to alert clients to changes

INITIAL POPULATION

INITIAL POPULATION

RESULT MAINTENANCE

RESULT MAINTENANCE

DELTAS AND QUERY OPTIONS • Query options "preserved" in delta links • $filter, $select

DELTAS AND QUERY OPTIONS • Query options "preserved" in delta links • $filter, $select • Query options that can be applied to delta queries • $top, $skip, $format, $inlinecount • Query options that are not applicable to deltas • $orderby • $count, $value

DELTA RESULTS • Delta results are ordered by when change occurred • Payload shows

DELTA RESULTS • Delta results are ordered by when change occurred • Payload shows current values • Clients can merge with local results • Add Tombstones to represent removed rows • Contains ID of removed entry • May contain a "reason" o Hard-delete versus no longer member of the group (i. e. , due to change)

DELTAS AND SERVER DRIVEN PAGING • Delta Link returned on last page of results

DELTAS AND SERVER DRIVEN PAGING • Delta Link returned on last page of results • Makes sure deltas aren't applied to incomplete results • Results of delta queries may be paged • Each interim page has a next link • Final page may have a delta link for getting changes

ATOM FORMAT • <feed> contains a delta Link as a <link> element • href

ATOM FORMAT • <feed> contains a delta Link as a <link> element • href is the url to retrieve deltas • rel is "http: //odata. org/delta" • <feed> contains Atom "deleted-entry" elements for each deleted object deleted. Entry = element at: deleted-entry { atom. Common. Attributes, attribute ref { atom. Uri }, attribute when { atom. Date. Construct }, attribute m: reason { 'deleted' | 'changed' } } Where m: is the metadata namespace for data services: "http: //schemas. microsoft. com/ado/2007/08/dataservices/metadata"

ATOM EXAMPLE <feed> <title type="text">Customers</title> <id>http: //Delta. Service. svc/Customers</id> <entry> <id>http: //Delta. Service. svc/Customers('BOTTM')</id>

ATOM EXAMPLE <feed> <title type="text">Customers</title> <id>http: //Delta. Service. svc/Customers</id> <entry> <id>http: //Delta. Service. svc/Customers('BOTTM')</id> <title type="text" /> <link rel="edit" title="Customer" href="Customers('BOTTM')" /> <category term="Northwind. Model. Customer" scheme="http: //schemas. microsoft. com/ado/2007/08/dataservices/scheme" /> <content type="application/xml"> <m: properties> <d: Customer. ID>BOTTM</d: Customer. ID> <d: Company. Name>Bottom-Dollar Markets</d: Company. Name> <d: Contact. Name>Elizabeth Lincoln</d: Contact. Name> </m: properties> </content> </entry> <deleted-entry ref="http: //Delta. Service. svc/Customers('Cust 10')" when="2011 -02 -16 T 01: 00: 25 Z" xmlns=http: //purl. org/atompub/tombstones/1. 0 m: reason="deleted" /> <link rel=http: //odata. org/delta href="http: //Delta. Service. svc/Customers? $deltatoken=8015" /> </feed>

JSON FORMAT • "results" array has a "__link" property • Value is the URL

JSON FORMAT • "results" array has a "__link" property • Value is the URL • Tombstones • "results" array contains "__deleted" objects for each deleted entry o "id" property o "when" property o "reason" property

JSON EXAMPLE { "d": { "results": [ { "__metadata": { "id": "http: //Delta. Service.

JSON EXAMPLE { "d": { "results": [ { "__metadata": { "id": "http: //Delta. Service. svc/Customers('BOTTM')", "uri": "http: //Delta. Service. svc/Customers('BOTTM')", "type": "Northwind. Model. Customer" }, "Customer. ID": "BOTTM", "Company. Name": "Bottom-Dollar Markets", "Contact. Name": "Elizabeth Lincoln" }, { "__deleted": { "id": "http: //Delta. Service. svc/Customers('Cus 10')", "when": "/Date(1297187419617)/" "reason": "deleted" } }, ], "__delta": "http: //Delta. Service. svc/Customers? $deltatoken=8015" } }

OPEN ISSUES • How do we treat $expand in a delta query? • Is

OPEN ISSUES • How do we treat $expand in a delta query? • Is deleted reason optional? Is it hard to determine in some cases? What does the client do if not known? • Does a server always return a delta link if it can? Might it be expensive to generate?