Builds: don't delete them when a version is deleted #7679
Conversation
We lose information when a version is deleted. Setting the version to null allow us to keep the builds around. But now we need to save more data to be able to reproduce some links. A data migration is needed to update old builds, but isn't required, as we fallback to the value from the version. Close #7674
| def get_version_type(self): | ||
| if self.version: | ||
| return self.version.type | ||
| return self.version_type |
There was a problem hiding this comment.
I wonder if we should just always use the denormalized values here. I don't think they'll ever change, hopefully.
There was a problem hiding this comment.
yeah, I think is better to use the saved values, since they are from when the build happened, if they change, they aren't part of that build anymore. I'm doing this for now till we fully migrate the data from the old builds. I'm worried that would take some time as we would be iterating over each build D: maybe do the data migration in another PR?
| Build = apps.get_model('builds', 'Build') | ||
| for build in Build.objects.all(): | ||
| # When the build is saved, the fields are updated. | ||
| build.save() |
There was a problem hiding this comment.
I'm worried about this migration... I think is going to take a while, and maybe block the table? We could also do this incrementally, this is by overriding the delete method of the version (or use the pre-signal) and update all of their builds before that.
There was a problem hiding this comment.
I don't believe it will block. It's basically just running the Python code -- but we should definitely be using an iterator() here, or finding another clean way of handling this without eating a ton of memory.
There was a problem hiding this comment.
updated! Also, we can run 0032 and 0033 after the deploy, so we don't need to wait so long before deploying the webs.
There was a problem hiding this comment.
I have added that note in the release board
| Build = apps.get_model('builds', 'Build') | ||
| for build in Build.objects.all(): | ||
| # When the build is saved, the fields are updated. | ||
| build.save() |
There was a problem hiding this comment.
I don't believe it will block. It's basically just running the Python code -- but we should definitely be using an iterator() here, or finding another clean way of handling this without eating a ton of memory.
With builds/0032 the migration was taking too long. Migrate old builds before the version is deleted instead. Ref #7679
With builds/0032 the migration was taking too long. Migrate old builds before the version is deleted instead. Ref #7679
We lose information when a version is deleted.
Setting the version to null allow us to keep the builds around.
But now we need to save more data to be able to reproduce some links.
A data migration is needed to update old builds, but isn't required,
as we fallback to the value from the version.
Close #7674