Issue with updating DependantVersionEffectiveTime in CodeSystem Version
Opened this issue · 4 comments
The problem arose with updating the value of dependantVersionEffectiveTime in the code system version. The sequence was as follows:
- CodeSystem.dependantVersionEffectiveTime was set to 20240201.
- Imported the international edition MAIN/2024-04-01.
- Then imported the EE edition MAIN/SNOMEDCT-EE/2024-05-30.
- Updated CodeSystem.dependantVersionEffectiveTime to 20240401, but the dependantVersionEffectiveTime of the latest EE edition remained 20240201.
No possibilities of updating dependantVersionEffectiveTime CodeSystem version were found.
The steps should be:
- Importing new International Edition release package
- Upgrade the extension codesystem (SNOMEDCT-EE) using
POST /codesystems/{shortName}/upgrade
- This should automatically change the dependant effective time
- Import the new extension release package
- This will create the new extension version within Snowstorm with the correct dependant version
It's not possible to manually set or override the dependant effective time. This is calculated by the Snowstorm version control system.
Technical explanation..
Each child branch points to a specific commit on the timeline of the parent branch, this is called the base timepoint. The dependant effective time is taken from the codesystem version of the parent code system that matches the base timepoint.
It is essential to upgrade an extension codesystem before importing the new extension release package, this ensures good referential integrity of the internal semantic index. If the release package is imported first it's possible that new concepts may point to International concepts that the extension branch can not see yet.
@kaicode Thank you for the answer! Unfortunately, it is not possible to delete the code system version after it has been imported, nor is it possible to directly fix the incorrect dependant effective time field. What should be the next steps to fix this incorrect import?
I recommend reverting one or two commits on the extension branch. This will automatically delete the codesystem version and reset the content ready for the upgrade step.
Follow these steps to rollback the correct number of commits on the codesystem branch to the point of the previous release:
-
Get the previous release branch to check the branch state
- Use
GET /branches/{branch}
. For exampleGET /branches/MAIN/SNOMEDCT-EE/2023-11-30
. - In the response the branch
state
is shown.
- Use
-
The state of the previous release branch is dependant on the content of the codesystem branch.
- The codesystem branch in this example is
MAIN/SNOMEDCT-EE
- The codesystem branch in this example is
-
If the previous release branch state is
UP_TO_DATE
that means the codesystem branch does not contain any changes since the latest release import and there is no need to rollback. -
If the previous release branch state is
BEHIND
that means the codesystem branch contains changes since the latest release import that should be rolled back before importing a new release. -
Rollback one commit on the codesystem branch:
- Get the codesystem branch using
GET /branches/{branch}
. For exampleGET /branches/MAIN/SNOMEDCT-EE
.- Make a note of the
headTimestamp
. For example1701321893134
.
- Make a note of the
- Use the admin rollback function to revert the head commit of the codesystem branch
- Use
POST /admin/{branch}/actions/rollback-commit
, supplying the codesystem branch and the head timestamp.
- Use
- Get the previous release branch. If the status is
BEHIND
that means the codesystem branch needs rolling back further. Follow these steps again to rollback another commit. Repeat as many times as needed.
- Get the codesystem branch using
You should only need to rollback a few commits. Once the previous release branch state is UP_TO_DATE
the codesystem is ready for upgrade. After upgrading import the new extension release package.