-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Skip default delete #2456
Skip default delete #2456
Conversation
759dae4
to
47ade26
Compare
Does the PR have any schema changes?Looking good! No breaking changes found. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, although I'd be more confident with some test coverage.
Expose only a method rather than the internal data structures.
- Use nil to indicate we don't have a default state defined instead of HasDefault. - Expose standalone SkipDeleteOperation function for the provider. - Call into defaults function directly from the provider rather than serializing more properties into the metadata. - We can't skip serializing the DefaultBody as there's some cases where it's implicitly set based on a `/list` path existing. - Panic if we define duplicate default resource states (after normalization).
fb63ddf
to
045090a
Compare
Is this a breaking behavior change? Have we documented it anywhere? How did we decide it's okay to ship it? Is it temporary until a better fix lands? What is our principle how to decide for which resources this is okay to apply? |
}, | ||
HasNonEmptyCollections: true, | ||
} | ||
assert.Equal(t, &expected, actual) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please explain what we are testing here? GetDefaultResourceState
does two things:
- Calls
NormalizePath
- Calls a map lookup and returns the value or default
What do we get by having 5 tests for it? It feels like we are testing the contents of defaultResourcesStateNormalized
?
…#3076) This PR fixes what I believe is a bug introduced in #2456. For the default state of a resource, we need to distinguish between `nil` (no default) and the empty object as the empty default. This is also described in the doc comment of `AzureAPIResource.DefaultBody` in resources.go: > - omitempty is not set to distinct between nil (no default) and empty maps (empty default) `AzureClient.CanCreate` checks `DefaultBody != nil` to detect resources that are automatically created with their parent. The actual change in metadata is not visible in the PR because we don't commit it. It looks like this: ```diff --- ../m-master.json 2024-02-12 20:22:54.578408624 +0100 +++ ../m.json 2024-02-12 20:21:14.881957652 +0100 @@ -1005922,7 +1005922,7 @@ ] } }, - "defaultBody": {}, + "defaultBody": null, "putAsyncStyle": "azure-async-operation", "deleteAsyncStyle": "azure-async-operation" }, ```
For resources without DELETE operations defined (only PUT) and no obvious "default" state to reset to, add the option for delete to be a no-op.
This is required for Sql database TransparentDataEncryption which requires different properties to be set for different API versions. This could be solved by introducing version awareness, but that would be a larger piece of work.
We model skipping the delete by setting the "default body" to nil.
This includes a refactor to disentwine path normalisation and default resource state from the main discovery process. These are moved into their own modules so only public members can be interacted with - to avoid interacting with the wrong internal parts.