Data Types and Versioning
As the HealthVault team modifies existing HealthVault data types to better meet the needs of solution providers, one of the issues we're examining is versioning. Consider the following situation:
Application A is deployed using the current version of the Encounter type (V1). Users use the application, and it writes instances of the Encounter type to the users' data records.
Application B then requests that the HealthVault team modify the type. Assume that we decide to add a new field and change the type of a field from string to CodableValue. This version is Encounter type V2. We w to deploy it to the servers so that Application B can now use this new type, but if we do and Application B starts using it, Application B is going to break when it reads Encounter records from Application A, and vice versa.
The solution to this is a new feature that allows applications to see the view of an object that is correct for the version of the SDK that the application is using, without knowing the actual version of the object. If your application is built using the V1 library, when you query for Encounter objects, the platform ensures that you get the version that your library can understand.
Providing a seamless solution for updates is more complex, and we’ve decided to prohibit cross-version updates (that is, V1 cannot update V2 objects), at least for the first release. We believe that updates are rare enough that this is an acceptable restriction.
We had hoped that this solution—which is scheduled to be shipped in Summer 2008—would be ready before we needed to modify any of our current data types, but solution providers are looking for changes earlier rather than later, so we've come up with a near-term solution as well.
The near-term plan is to explicitly version any type that we need to modify. Using Encounter as an example, we rename the existing Encounter type to EncounterOld, and then create a new type for the modified type, named Encounter. Your application may have to be modified, depending on how you want to deal with the presence of the new type:
- If you want to switch over to using the new version, you merely need to recompile
- If you want to continue to use the existing type and deal with any changes later, you have to change any occurences of Encounter to EncounterOld and recompile. This gives you identical behavior and you can access any existing Encounter instances stored in the record
- If you want to support both versions in the same application, you have to write explicit code in your application to do so
When the versioning work is released, all instances of the Encounter type (or any other versioned type) appear to applications as if they were the appropriate type.