-
Notifications
You must be signed in to change notification settings - Fork 18
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
[SDK] Adds consistent parameter validation #158
[SDK] Adds consistent parameter validation #158
Conversation
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.
Designating @likawind as lead reviewer but tagged the other two in a question.
), "New spec has a different type." | ||
|
||
self.operators[str(op.id)].spec = spec | ||
self.operator_by_name[op.name].spec = spec |
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.
This seemed safer than the blind replace of operators we currently have. Plus, we can add additional validation on the operation.
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.
What's the main downside of direct replacement?
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.
It's just bit uglier from the callers side, since editing an operator always requirements a fetch and replace. With this we can just construct the new spec from scratch. Replacing an operator fully might be better in the long term though, not sure.
sdk/aqueduct/dag.py
Outdated
|
||
if any(not isinstance(name, str) for name in self.parameters): | ||
raise InvalidUserArgumentException("Parameters must be keyed by strings.") | ||
check_overwriting_parameters_are_valid(dag, self.parameters) |
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.
maybe validate_overwriting_parameters
?
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.
Great! I think this type of checking could be generalized to ensure all operator inputs are properly typed (e.g. you shouldn't pass a string params to an df function), but that's not immediate.
Describe your changes and why you are making these changes
Both get() and trigger() allow for execution of flows with different parameters. This pipes any user-defined dictionary of overriding parameters through the
check_overwriting_parameters_are_valid()
helper, which validates that the new parameter values in the dictionary can be used on the dag.get() uses the dag of the artifact. trigger() now uses the latest run of the flow. If there isn't a run of the flow yet, it'll throw an exception.
Related issue number (if any)
ENG-1144
Checklist before requesting a review