Sprint 3 for SQL Server Data Services Will Add Several New Features

An e-mail from the SQL Data Services (SSDS) team dated July 8, 2008 announces that Sprint 3 will add support for Blobs, timestamp versioning, ETag, HEAD, If-Match, Accept and a new content type when the latest update goes live.

Following are the details (verbatim from the e-mail except for my notes) for those who haven’t yet been inducted into SSDS’s limited beta program:

Blob Support via the REST interface:

• Support for storing unstructured Blob data has been the most requested feature.
• Blob support via the SOAP interface is coming.
• In the beta release, Blobs are limited to 100 megabytes in size.

Version metadata property has been changed from an integer to a large integer:

• Version numbers are now based on a timestamp and will not monotonically increase as before.

ETAG and HEAD support via REST, with similar functionality via SOAP

• Support for If-Match and If-None -Match via the REST interface. This will allow you to verify that you have a current Entity enabling you to use resources more efficiently.
• Support for "Accept" header via the REST interface. This will allow you to denote what content you want returned from the service. For instance when retrieving a Blob, the "Accept" header will allow you to choose between the Blob content, or the metadata properties associated with it.
• Note: This is consistent with ADO.NET Data Service’s concurrency management approach (see the Astoria team’s Optimistic Concurrency & Data Services post of 4/22/2008.)

A new content type - "application/x-ssds+xml" has been added to the service

• This content type is for storing XML content in the service.
• Existing "application/xml" content type is being phased out in a future sprint.
• The "application/x-ssds+xml" content type should be used for all entities except those containing blob content. Blob entities should instead use a content type value which best reflects the type of blob data stored. It's important to note that the value chosen here will be used later when attempting to retrieve the different parts of an entity by using the, "Accept" header.
• While the "application/xml" content type will still be supported in the short term, we highly recommend that you begin to migrate your applications to the new "application/x-ssds+xml" content type.

Notes: The SSDS team says the “updates will be coming in a few weeks” and all data uploaded to Authorities will be deleted with one week’s notice. You can expect instructions for implementing the client side of new features to be posted in the SSDS blog, SSDS forum and the main SSDS page on MSDN.

I had expected Sprint 3 to implement full-text search on SSDS’s front-end. It was rolled out on the back end in Sprint 2 (see Soumitra Sengupta’s Confusion about Full Text Search in SSDS post of June 22, 2008).

Hopefully, Ryan Dunn will extend his SSDS client class library (described in Working with Objects in SSDS Part 3 and earlier) to accommodate the new features.

Technorati tags: SQL Server Data Services, SSDS, SSDS Provisioning, ADO.NET Data Services, Astoria Project