|
<< Click to Display Table of Contents >> NShape Concepts
|
  
|
|
<< Click to Display Table of Contents >> NShape Concepts
|
|
Repositories are versioned to support backward compatibility. Version numbers are simple integral numbers. Besides a general version number for the built-in classes, the repository holds a version number for each shape or model object library. This version number identifies the version of the shape or model object library that was used to create the store. It is necessary to have separate version number for each library because libraries might be enhanced independently from each other and from the built-in classes.
The framework supports versioning by supplying the library versions of the current repository store in the project and by storing the library version in the repository store when creating a new project. Shapes and model objects support versioning by loading and saving their data depending on the version of the repository. They also provide their description of the conceptual data model in correspondence to the library version.
Scenarios where a library writes an older repository format than its current one are not supported.
Let us assume that company A has created a shape library for framework version 1.2, which contains shape derived from standard shapes in the General Shapes namespace. Company A assigns version 1.2 to this library.
Now, company A develops a new version of their library called version 1.3, which is still based on framework version 1.2. It is written so it can read repositories created with version 1.2 but creates extended repositories. The framework supports this scenario by storing the assembly versions in the repository and passing it to the entities being loaded. When a repository containing 1.3 shapes is opened, these shapes receive the 1.3 version and know how to load themselves. Because these shapes are based on 1.2 general shapes, they pass the older version to their base classes for loading.
In the second scenario, company A's library is not updated and stays at version 1.2. However, a new version 1.4 of the framework is released, which writes extended data for the General Shapes namespace. Because the company A's library is not updated, the contained shapes still rely on the 1.2 version of general shapes and therefore, both versions of that library must be loaded. The general shapes in the older library will not be registered, but they still serve as the base classes for company A's shapes. Even when a repository is opened which contains 1.4 shapes, the load methods for the company A shapes are still called with 1.2 as the version number.
In order to update a repository from version 1.2 to one of the two described mixed states, it must be opened with AutoLoadLibraries switched off. Then, the application must register the new libraries and make sure that the complete project is written back to the repository. If the repository is based on an RDBMS, a schema for the new version of the repository must be created first.