Harden RepositoryVersion against memoization issues#7311
Conversation
eedd748 to
366381e
Compare
|
Working on getting some additional tests + making the output of the data repair command more reasonable. Also fixing failures. Also adding tests for add / remove / contents >65535 packages re: #5375 Question: should I leave a copy of the old data repair command until 3.115? |
012e5cd to
36bd060
Compare
cfb77c2 to
7e70dd7
Compare
2f78664 to
77971fe
Compare
1309c12 to
4741e69
Compare
3d29363 to
2199570
Compare
4885a49 to
ac93a91
Compare
| content_artifact = ContentArtifact.objects.create(content=content, relative_path="test/path") | ||
|
|
||
| # Attempting to add a queryset of ContentArtifact (not Content) should raise AssertionError | ||
| with pytest.raises(AssertionError): |
There was a problem hiding this comment.
Type analysis would have caught that too, i think. But we don't have that. So 👍.
| with repository.new_version() as version2: | ||
| # Remove content that doesn't exist (no-op) | ||
| version2.remove_content(Content.objects.filter(pk=9999999)) | ||
| # Add content that already exists (no-op) | ||
| version2.add_content(Content.objects.filter(pk=content_pks[0])) | ||
|
|
There was a problem hiding this comment.
Do we also have as similar test, where the single content is actually removed and then added again so still no new version is generated?
There was a problem hiding this comment.
Yes, test_version_identical_to_previous
There was a problem hiding this comment.
Well, that tests "adding and then removing" the same content, so I will extend to also cover "removing and then adding" the same content
325dee4 to
e088712
Compare
e088712 to
e5e3c69
Compare
| """ | ||
| with transaction.atomic(): | ||
| # relatively inexpensive sanity check for memoization | ||
| assert len(self.content_ids) == self._content_relationships().count() |
There was a problem hiding this comment.
So basically this is checking that at the end of squash(), that the 'cached' content_ids field of the repoversion, has the same number of elements as recomputing - so this would be like a last-ditch chance to catch coding-errors in "someone's" new-version-creation code, yeah?
Even if it's "just" a count() of the recompute-query - is this actually "inexpensive"? (thinking out loud here) It would only happen once at new-version-squash-time, so that may not be a big issue.
There was a problem hiding this comment.
My thinking here is that it's at least not any more expensive than the operations that already have to happen at the beginning of the repository version create (basically this same query) and at the end, including the annotates below.
There was a problem hiding this comment.
And probably much less so
closes: 7272 Assisted By: claude (tests only)
e5e3c69 to
e447ce5
Compare
ggainey
left a comment
There was a problem hiding this comment.
Looks good - and thanks for the extensive test-suite additions!
Backport to 3.73: 💔 cherry-picking failed — conflicts found❌ Failed to cleanly apply a6c1a8e on top of patchback/backports/3.73/a6c1a8ec470ccbc18bbb0512dfa6aafa4429e6fa/pr-7311 Backporting merged PR #7311 into main
🤖 @patchback |
Backport to 3.103: 💚 backport PR created✅ Backport PR branch: Backported as #7328 🤖 @patchback |
Backport to 3.85: 💔 cherry-picking failed — conflicts found❌ Failed to cleanly apply a6c1a8e on top of patchback/backports/3.85/a6c1a8ec470ccbc18bbb0512dfa6aafa4429e6fa/pr-7311 Backporting merged PR #7311 into main
🤖 @patchback |
📜 Checklist
See: Pull Request Walkthrough