Request and response types #27
Conversation
| // resource. An instance of this request struct is supplied as an argument to | ||
| // the resource's Read function. | ||
| type ReadResourceRequest struct { | ||
| // tfprotov6.ReadResourceRequest has no Config field |
There was a problem hiding this comment.
There's no Config field in tfprotov6.ReadResourceRequest. Should providers have access to config during Read?
There was a problem hiding this comment.
I believe providers only have access to the existing state during read.
|
Requesting review on this now for the included fields, functions, documentation, and names. We can't merge until we have The only functions defined on the response structs at the moment are diagnostics helpers. Inside the CRUD functions themselves, providers can manipulate state and plan fields by calling their Get and Set methods directly, e.g.: func (c computeInstanceResource) Create(ctx context.Context, req framework.ResourceCreateRequest, resp framework.ResourceCreateResponse) {
req.Plan.Get(...)
resp.State.Set(...)
}We could use the same paradigm for diagnostics (as described in #24), defining a resp.Diagnostics.AddWarning(...)I've included the alternative here to see what it looks like, but I think I'm inclining toward the same approach for both state/plan and diagnostics, which would involve removing the diagnostics funcs from this PR and implementing #24 for this PR to depend on. |
I'm in favor of this, and think it's a fine change to make as part of #24. |
Add request and response types for Provider.Configure and the resource CRUD functions.
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
closes #13
This PR defines:
ConfigureProviderRequestConfigureProviderResponse{Create,Read,Update,Delete}ResourceRequest{Create,Read,Update,Delete}ResourceResponseNeeds
StateandPlantypes (#26) before it will compile.