cnlbob
commented
9 years ago There really is no global CellBlender API version. We've implemented a 2-level versioning system:
- Fine-grained fingerprint versioning reflected in the cellblender_id.py file
- Coarse-grained data model compatibility and upgrading distributed throughout the classes
The basic idea is that we store a python dictionary "data model" that represents the key data elements needed to describe an MCell model. Whenever the fine-grained (SHA1-sum) of the add on source files differs from what was stored in the .blend file, then all of the CellBlender properties will be rebuilt from that stored python dictionary "data model". This provides consistency across minor changes.
When major changes to the data model itself are needed, they are handled by each component. For example, if our molecule representation were to include another new field, then the molecule class would be responsible for identifying molecule data models that needed to be upgraded to the new molecule API. This is typically done by storing a marker string named "data_model_version" inside each component. These version strings are only meaningful within each component. So if the molecule class were to change its representation, then it would tag that new representation with a new "data_model_version" string attached only to the molecules. The rest of the components (reactions, model objects, viz output settings, partitions, ...) would not get a new version number because they hadn't changed. Only the molecules class would have changed, and that change would be recognized by the molecule class code.
The process of reading a .blend file is as follows:
- Compare the global SHA1 of the CellBlender source with the SHA1 in the .blend file. If they match, then no other action is needed - all properties should match the addon.
- If the SHA1 didn't match, then open the data model and "upgrade" it to match the addon. Upgrading is a series of sequential changes for each component to get to the next version.
- After the upgrade of each component (molecules, reactions, etc), check for a match. If the local version of any component doesn't match after the upgrade, then report an error. If none of the components has reported an error, then copy the data model into the properties.
The current "warning" issued when the data model cannot be upgraded to match the addon is to simply exit Blender. This is done via the "handle_incompatible_data_model" function in the data_model.py file. Whenever any component (molecules, reactions, etc) cannot upgrade its data model (most likely due to a newer file opened by an older addon) it calls that function which currently exits Blender (it might take some other action in the future).
This behavior might be sufficient to close this issue.
CellBlender should issue a warning if a blend file is opened with an API version that is later than the current version of CB (e.g. opening a CB 1.1 blend file with CB 1.0).