-
Notifications
You must be signed in to change notification settings - Fork 190
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
Reference output_wrapper_field_path
when generating CRD fields as part of the Create*
request in model.go
#210
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -110,23 +110,14 @@ func SetResource( | |
if op == nil { | ||
return "" | ||
} | ||
outputShape := op.OutputRef.Shape | ||
outputShape, _ := r.GetOutputShape(op) | ||
if outputShape == nil { | ||
return "" | ||
} | ||
|
||
var err error | ||
// We might be in a "wrapper" shape. Unwrap it to find the real object | ||
// representation for the CRD's createOp/DescribeOP. | ||
|
||
// Use the wrapper field path if it's given in the ack-generate config file. | ||
wrapperFieldPath := r.GetOutputWrapperFieldPath(op) | ||
if wrapperFieldPath != nil { | ||
outputShape, err = r.GetWrapperOutputShape(outputShape, *wrapperFieldPath) | ||
if err != nil { | ||
msg := fmt.Sprintf("Unable to unwrap the output shape: %v", err) | ||
panic(msg) | ||
} | ||
sourceVarName += "." + *wrapperFieldPath | ||
} else { | ||
// If the wrapper field path is not specified in the config file and if | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, but why didn't this block of code pick up the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This code works as intended. The issue was I added There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would like to clarify that the original use for What we are adding in this is support for Some of the code changes @brycahta has made are re-using existing parts of the code that worked with the describe output to also work with create. I believe this is one of those elements. |
||
|
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.
You'll probably want to handle this error, as it's critical. A panic might be a fair response if this returns an error - you cannot find the shape to use.
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.
GetOutputShape
has a panic for that scenario. I kept logic consistent with previous behavior when refactoringThere 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.
But the method does throw other errors apart from that panic.
I think it makes sense to catch error and panic
(OR ugly version would be to panic for all errors inside
GetOutputShape
and removeerror
from return type)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.
I disagree with catching error and panic for this. Throughout the code having a
nil
shape is not considered an error (ex: line 114 here), and I don't think it'd be correct to start doing so now.Your suggestion with removing
error
return type sounds like the right way to go. However, I wouldn't panic for all errors just the scenario where there's a wrapper override that is expected to work. What do you guys think?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.
Fair enough...
Since in the existing code outputshape is being returned as nil and then it is being handled in line 114, we do not need the error in method signature.
I would be onboard with removing error from method signature and keep the panic statement in method body