Query Continuations in Data Services

This is the second part of the server paging in ADO.NET Data Services - see Server Paging makes for happy servers for the first part.

When working with queries that return paged results, it may seem overkill to have a specific class, DataServiceQueryContinuation, just to handle the URI to the following page that the server returns. Particularly one with with such a long name. Besides, the class does expose the NextLinkUri in any case, right?

While it may be tempting to just load from that URI to return the rest of the results, avoid the temptation. The continuation actually does hold more information than just the URI. In particular, when you use projections / $select to reshape the results, the query continuation internally knows how to process the results so they come back the right way.

Think of it this way: if you run a query such as var q = from c in ctx.Customers select { FullName = c.FirstName + " " + c.LastName }, clearly a simple URI doesn't hold enough information to page through the results. The URI will be able to get the second page of customers, but the local concatenation to initialize an anonymous type isn't something that the URI holds, because the server that produces this URI has no idea of what the client library wants to do with the information.

Besides, the DataServiceQueryContinuation<T> type is a generic with strongly-typed element type so you can invoke the appropriate DataServiceContext.Execute method on it and never have to typecast any results - and who wouldn't want that?


Comments (0)

Skip to main content