EES-5416 Fix release files not being unlinked when draft data set versions deleted #5153
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes a bug where
ReleaseFiles
would continue to reference draft data set versions after they had been deleted. This was due to a couple of issues:ReleaseFile.PublicApiDataSetVersion
column as well. We now update this when the version number changes.ReleaseFile.PublicApiDataSetVersion
. We were querying with the 'public' version number (using non-standardmajor.minor
), whereas thePublicApiDataSetVersion
is stored with a standard semversion number (usingmajor.minor.patch
).To help differentiate between these two version numbers better we've made the following changes to
DataSetVersion
:Version
getter is nowPublicVersion
(themajor.minor
number)FullSemanticVersion
method is nowSemVersion
(themajor.minor.patch
number)Breaking changes⚠️
As part of this, the blob / file storage path has been changed to use the semversion, rather than the public version. This is a breaking change to existing file paths on dev.
Existing API data set versions will be affected until we clear down the files, otherwise, new API data set versions should work.
Why have patch version numbers?
Currently, we don't use patch version numbers, but we may need these in the future so we're trying to support them as early as possible in case.
One potential use case are data file replacements where we may want to update the underlying data. A data replacement could be considered a bug fix for data and hence has parallels with patch versions.
Replacements are currently not supported by API data sets, but they will be considered further in post-MVP.