Simplify the name update call stack #1385
Conversation
|
LGTM |
There was a problem hiding this comment.
RemoveNames and AddNames are not deprecated instead they were added only to deprecate racy SetNames. Here: #1153
Downstream is still using RemoveNames or AddNames and this breaks public API without any deprecation notice IMHO.
Last switch in one of the downstreams happend here containers/buildah#4190 but there are many more PR's.
Edit: It seems most of the invocation is using Store's API but I am not sure if any invocation is directly using Container,Image or Layers's API
|
I'm fine with dropping the methods from rwLayerStore/rwImageStore/rwContainerStore - those are package-private types. The exported interfaces don't change, so LGTM. |
Ah i see, SGTM as well since I see downstreams only using @mtrmac There is a conflict in the PR though, could you please rebase. |
Instead of going 3 store methods store.updateNames+enum 3 sub-store methods subStore.updateNames+enum applyNameOperation+enum, simplify to 3 store methods store.updateNames+enum subStore.updateNames+enum applyNameOperation+enum, Should not change behavior. Looking purely at updateNameOperation, invalid values would now be detected after doing more work, but there is no way for an external caller to trigger use of an invalid value anyway. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
|
Rebased, tests pass. |
Instead of going
simplify to
Should not change behavior. Looking purely at
updateNameOperation, invalid values would now be detected after doing more work, but there is no way for an external caller to trigger use of an invalid value anyway.